Identity Metasystem - Information Card Implementation
How Identity Metasystem Works
Figure 1: Identity Metasystem
Let's get down to what is happening:
Remember the three parties involved in the Identity Metasystem? You might want to visit the introductory post here.
We have the subject who could be you. Normally the subject has several identities stored in the identity selector (Information card client). These identities have been obtained from different independent Identity providers (1-N). The subject is using an application (service requester). This could be a browser or any other application. The subject is accessing resources from any of the relying parties (1-N) that must support Information Card.
Step 1: The user tries to access resource on a relying party (labeled 2). The user is redirected to a login page that contains a link of which when the user clicks, the information card will activate (explained later).
Step 2: The following sequence follows:
a) In the background, the relying party expresses the set of claims it requires in order to authenticate. A claim is a statement made about the subject; could be first name, last name, date of birth and so on. These claims requirements are transferred to the identity selector in the relying party's policy, using WS-MetadataExchange.
b) The information card is activated and its user interface is displayed on the screen. If the user is accessing this resource for the first time, the identity selector will indicate this, provide the relying parties certificate details (especially who's the Certification Authority that vouches for the relying party's authenticity).
The user can then make a decision based on this whether to trust this relying party or not. If the user clicks yes on the dialogue, the user's collection of cards that are in the identity selector are displayed. Some cards might meet the relying party's policy, others might not. Those that meet the requirements will appear active, while those that don't will appear grayed out.
The user might then select any of the active cards by double clicking. In our case, the user selects a card that happens have been obtained from identity provider labeled (1).
Step 3: The identity selector prepares an RST (Request Security Token) that contains the relying party's claims requirements. The RST is sent to the identity provider.
Step 4: The identity provider must implement STS (Security Token Service). When it receives the RTS, it will in return supply a security token that contains the required claims. It passes the signed security token back to the identity selector, using WS-Trust.
Step 5: The identity selector then presents the signed token to the relying party, which decrypts the token, reads the claims it required and authenticate or otherwise. The user can then access the resource.
NB: We have skipped some details - for instance the signing of the token with the proof-of-possession key - for simplicity. To get the details, go to the links provided in the previous article.
лл Previous article.
Comment on this article
Create an article. Click here
Articles feed: 
