Now, that you, as the user, let the RP in (please see my previous posting) based on RP’s certificate and logos, RP, in turns, could express its security token requirements to you before it grants you some access. 

 

Consider the following xml fragments that RP could specify in its App.Config.

<security authenticationMode="IssuedToken" >

   <federationParameters>

          <tokenRequestParameters>

             <xmlElement>

                <wst:TokenType>
                     urn:oasis:names:tc:SAML:1.0:assertion
                 </wst:TokenType>

             </xmlElement>

             <xmlElement>

              <wst:Claims>

                 <wsid:Claim wsid:URI="http://.../identity#E-Mail-Address"/>

              </wst:Claims>

              </xmlElement>

              <xmlElement>

                   <wst:Issuer>
                      http://schemas.xmlsoap.org/ws/2004/10/identity/issuer#Self
                   </wst:Issuer>

              </xmlElement>

          </tokenRequestParameters>

   </federationParameters>

</security>

 

This App.Config will be translated automatically by Indigo runtime in the form of WS-SecurityPolicy.  The client could retrieve this information using WS-MetadataExchange – more later.

Note: In subsequent beta release, it’s very likely that the format of this app.config will change.

 

As you seen above the xml fragment, the RP specifies:

1.      The authentication mode to be “IssuedToken”.  If the Indigo runtime on the client sees this, it will call InfoCard System.

 

2.      Token Type is SAML:1.0.  The interesting thing to note here is InfoCard could work with any type of token, as long as Identity Provider (IP) could satisfy the request.  InfoCard is token agnostics. In the future, if a claim based token format is invented, InfoCard system could still work, provided that RP asks and consumes the token and IP produces the token.  The role of InfoCard, as an Identity Selector is to be a match maker between RP and IP.

 

3.      Claims requested by the RP.  In this example it’s E-mail address. Note the claim is identified by the URI.  Other company could in, theory, define Email Address with a different URI, for example http://schemas.fabrikam.com/2005/07/claims#E-Mail-Address.

 

4.      Finally, the RP specifies the issuer of this token. In this example, RP would like a self-issued token.  RP could also omit this, indicating any issuer is acceptable.  Or RP could specify a specific issuer; for example,
http://services.contoso.com/products/sts

 

To retrieve this RP’s policy, the client could use svcutil.exe (for design time), or it could also use MetadataResolver (for runtime).

EndpointAddress mexAddress = new
                EndpointAddress("http://.../mex");

 

MetadataResolver mexProxy = new MetadataResolver(mexAddress);

 

ServiceEndpointCollection endpoints = mexProxy.RetrieveEndpoints();

 

// for simplicity, brevity, assume only one serviceEndpoint
ServiceEndpoint ep = endpoints[0];

// Create a channel based on the the end point
ChannelFactory<IHello> cnFactory = new
                       ChannelFactory<IHello>(ep.Address, ep.Binding);

IHello chn = cnFactory.CreateChannel();

 

That’s it.  The client points to RP’s MetadataExchange endpoint, and retrieves RP’s WSDL (including the security policy) to form a serviceEndPoint collection.  Once the client finds the serviceEndPoint it wants, it calls Indigo to create the channel.

What happen under the hood (on the client side)?

 

1.      Indigo calls InfoCard System, since RP asks for “IssuedToken”

 

2.      Let’s assume user has a few cards issued by different companies, government, and self-issued.  InfoCard System will match the RP requirements with the cards that are capable of satisfying the RP’s requests (please see point 1-4 above)

 

3.      User is presented with the qualified cards.  User selects a card.

 

4.      InfoCard System will read the card (remember it only contains a metadata about how to get the token), and contact IP.

 

5.      InfoCard uses WS-Trust to get the token from IP, passes the RP’s security policy along with it.

 

6.      InfoCard gets the token from IP, asks the user for her approval prior to submitting the token to RP.

 

7.      Token is sent to RP, encrypted with RP’s public key.

 

We’ll examine InfoCard and IP interaction in later postings.

 

Oh…, one more thing – I’ll be taking three week vacation starting in a few hours…J; it could be challenging to get Internet connection in some remote areas – so I won’t be updating this blog for a while. I plan to capture some of interesting, real-life  IP – Client – RP and STS scenarios, in the form of ---what else - pictures.  I just picked a new hobby of digital photography; it’s great to learn the “language of photography” like metering, white balance, parameters, af-points, shutter, aperture, depth-of-field, etc; I could always use some advice.

 

See you in a bit ...