SharePoint Claims Based Authentication – Delegating Claims
Delegating the use of claims is important to cover as well. One application may need to access another application for a given user. This problem will take the use of identity delegation to solve it. Then the first application will provide the second one with the user information required to allow them to access both of them. This delegation process is a vital part of what already takes place in the world of business. However, with claim based identity it will advance to a higher level.
In this example the user gets a token from an application X. The token is sent to application X but to do so the service may require something from an application Y. Application X will get a token for application Y that has all of the claims that the original user should have access to. In order for this token to be generated, application X will need to access application Y. This allows it to explore the requirements of the other application. The identity provider and STS from Y will accept a token. The STS can be the same for the two applications but it doesn’t have to be.
The AD FS v2 STS will have policies in it that determine which applications a given user will be allowed to access. The STS will check the policies that are in place and then issue a token based upon them. Application X will then pass this token to application Y where it is verified through the Windows Identity Foundation before the claims can be used.
There are a couple of ways to accomplish this. The user can use the same username and password from application X to access application Y. Yet that can often end up allowing a user access to things that they shouldn’t be approved for. The right way to take care of it with a claims based approach is to make sure X has a token to only allow the user of Y what they should. They don’t get access to anything beyond that.
Delegation can also be accomplished by making X a subsystem of trust. This means it will have complete access to the other services. This can only work though if the developer of such an application is an expert in setting it all up. For auditing purposes it needs to provide information about who from application X and who from application Y have accessed it.
The STS is a type of claims transformer here as well. When it gets a token for X then it will also offer a token for Y. These two tokens will have different information in them and may operate doffer of different formats. The good news is that all of that is behind the scenes so the user of the STS doesn’t have to worry about it.
Next Section >> Geneva Server – AD FS v2