SharePoint Claims Based Authentication Architectures Explained Part 2 Claims Architecture Priming
You can use one of many different types of approaches in order to create a claims based application. Both Web applications and SOAP Web Services can accomplish the same thing but they take different approaches for making it happen. Yet the overall structure that is there is the same as it’s the overall goal. The purpose is to create claims that can communicate with each other and that are secure.
We are going to take a close look at how you can evaluate the different types of architecture that can be used. Taking variables into consideration including different perspectives, the experience of the user, opportunities for optimizing, the performance of the different applications, and even how the claims get passed from the application to the issuer all need to be closely looked at. Only then will you see the entire picture of what is offered. I will also give you some advice about how to create your claims and how to know your users.
The overall purpose of the different architectures is to allow for either an active for passive type of federation to be implemented. With an active federation you will have the WS-Trust and WS-Federation Active Requestor Profile in place. They help to describe the way in which the communication between the clients and the services go about requesting a token from the issuer. It also covers how that token is sent for authorization.
With passive federation, the WS-Federation Passive Requestor Profile describes the same type of communication flow between the web application and the browser. In order for tokens to be requested and authorized the web browser has to redirect those requests.