| [higgins-dev] Use Case for Self Issued Token as User Credential |
|
Paul, Mike,
Here is the use case that was requested in this morning's Higgins call, regarding the use Self-issued credentials. I hope this is what is needed. I tried to give it some background and context. I don't know exactly who the audience will be, so for some it will probably be too much, and for others too little. I am open to all suggestions for improvement.
If there's something else people think is needed, please let me know.
Daniel Sanders
Some Background:
InfoCards exist on users' personal computers to more easily enable a user to manage and control what identity information - referred to as claims (name, email, phone, etc.) - they will give out to web services (relying parties). Claims are sent to a relying party in a "security token." A relying party can conceivably do many things with the claims contained in the security token - log the user into the web site, establish roles for the user, etc.
In CardSpace there are two types of InfoCards: managed cards and personal cards (also sometimes called self-issued cards). Managed cards are issued by Identity Providers. The IdP, along with the user, controls the dispensing of claims to relying parties. Identity information used to satisfy the claims is stored on some external identity system - it is not stored with the card. Personal cards are "self-issued" - the user has sole control over dispensing of claims to relying parties. The claims are stored with the card itself.
All cards have an associated STS (security token service) that can issue a security token when the card is selected by the user for interaction with some relying party. For Managed Cards, the STS will be hosted at some site on the network. It may or may not be associated with the IdP that issued the card. For Personal Cards, the STS is internal to CardSpace on the client machine.
When the user selects a card to interact with a relying party, CardSpace sends an RST message (request for security token) to the STS to retrieve the claims requested by the relying party. NOTE: For Personal Cards, it may be that CardSpace does actually send an RST message to the internal STS but simply invokes its internal STS to request a security token - the details of how this works are not really important.
When a user selects a managed card (as opposed to a personal card), the user is required to supply some kind of credential to the STS. The credential is included in the RST that is sent to the STS. The STS attempts to authenticate using that credential and, if it is successful, issues a security token containing the requested claims. When a user selects a personal card, the user is NOT required to supply a credential. Claims stored in personal cards are owned and controlled by the authority of the user that is currently logged into the client machine. The logged in user was authenticated at login time, so in normal circumstances there is no need for an additional credential. For the most part, it is assumed that the login authentication is sufficient authority to release the claims to a relying party. If desired, a user can require an additional level of authentication by "locking" a card with a PIN number so that the card can only be selected by someone who knows the PIN number. This is true of both managed and personal cards.
When a managed card is created, the card issuer can specify that it requires one of four types of credentials:
1) Username/password
2) Kerberos v5 Credential
3) Smartcard X.509 Certificate Credential
4) Self-issued Token Credential
Username/password is perhaps the most commonly used credential type. When the user selects a managed card where username/password is the credential type, CardSpace will prompt the user to enter the username and password before sending the RST to the STS.
Desired Use Case:
It is highly desirable that the user not be required to remember and enter a username and password every time they select a managed card. In a way, requiring a user to enter this information every time seems to defeat one of the important reasons for having a card in the first place - which is to simplify the user experience in their interactions with a relying party. A card that does not require the user to enter username/password is is preferred over one that does, because it greatly simplifies the user experience.
This is where the Self-issued Token Credential comes in. When a managed card specifies that a Self-issued Token Credential is to be used, the user is not required to enter anything when they select the managed card. This is because instead of sending a username/password, CardSpace will automatically create a SAML token that will be sent to the STS as the user credential. The SAML token will be embedded inside of the RST. The SAML token is really issued by the internal CardSpace STS, which is why it is called a "self-issued token."
We need to answer a very important question about this self-issued SAML token: Exactly what identity information does it contain that allows the STS use it to do authentication and lookup the identity information that is being requested by the managed card? It must contain the information needed to uniquely find the user's identity information. The following paragraphs attempt to explain how this happens.
First, to specify the use of a Self-issued Token Credential in the managed card definition, the issuer of a managed card must include the following XML:
<ic:UserCredential>
<ic:SelfIssuedCredential> <ic:PrivatePersonalIdentifier>base 64 PPID</ic:PrivatePersonalIdentifier> </ic:SelfIssuedCredential> </ic:UserCredential> The PPID (PrivatePersonalIdentifier) refers to a "personal card + some relying party." In this case, the relying party must be the site that hosts the managed card's STS. In essence, if the STS were acting as a relying party that had requested a PPID claim, and the personal card had been selected by the user, this is the PPID that would be sent to the STS. It uniquely identifies the personal card + the STS as a relying party.
When the managed card is selected by a user, the RST it sends to the STS will contain a SAML token as the user credential. The internal CardSpace STS issues the SAML token using the personal card that is referenced in the managed card definition. It is as if a user had selected the personal card and the relying party were the managed card's STS. In a way, that is exactly what is happening -- the "user" that selected the personal card is the managed card, and the relying party is the managed card's STS.
It follows from all of this that the issuer of the managed card will somehow have to obtain the PPID of a personal card with respect to the managed card's STS (as if the STS were the relying party). To do this, there will be some kind of card generation web service that will need to do the following:
1. Present a form to the user for generating a managed card. The form should require the user to enter information that enables the card generation service to find the user's identity information in the identity store (the reason for this is explained in step 4). This might be a username or an email address or something else. NOTE: It is assumed that the card generation service is able to access the identity store through the IdP. In addition to prompting for a username or other identifying information, the form should also have a button or a link that, when clicked, will cause the CardSpace card selector to be invoked to allow the user to select a personal InfoCard. NOTE: The underlying HTML form will have an <OBJECT> that requests a security token with a PPID claim. The <OBJECT> should also specify that the issuer must be "self" (there is a special URI for this) so that only personal cards can be selected.
2. When the user presses the button or link, the CardSpace card selector is triggered, and the user selects a personal card. The internal CardSpace STS issues a security token that contains the personal card's PPID with respect to the site that is hosting the card generation web service. The PPID needed in this case is the PPID of the personal card with respect to the site where the managed card's STS is hosted. Hence, the card generation web service needs to be hosted on the same site where the managed cards' STS is hosted. NOTE: The PPID claim is generated by CardSpace based on the site's SSL certificate. Hence, if the card generation web service is hosted on the same site as the managed card's STS, it will be the correct PPID for the managed card's STS. It makes sense for them to be on the same site, since the card generation web service is intended to create managed cards that use the STS to issue security tokens.
3. The card generation web service receives the security token and extracts the PPID as well as the Issuer Public Key. The PPID is inserted into the managed card definition (see above for the XML format), the managed card is created in an XML file (.CRD file), and the user is given a link to download and/or open the managed card. The user can import the card into CardSpace.
4. Using the username, email, or other identity information from the form (outlined in step #1), the card generation service looks up the user's identity in the identity store (by making appropriate requests to the IdP). It then creates an association between the PPID+PublicKey and the user's identity information so that PPID+PublicKey can be used later by the managed card's STS to lookup the identity information for the user. Some have recommended that the information stored should be hash(PPID,PublicKey) instead of PPID+PublicKey. This is up to the card generation web service and the managed card's STS - they just need to agree on how it should be done. There are also multiple ways the information might be stored. For example, it might be stored as an attribute (or multiple attributes) directly on the user's object. It might be stored in a separate table with a "pointer" to the user's object (the "pointer" being DN, UID, GUID, username, etc.). -- The point is that the information needs to be stored in whatever place and in whatever form the STS expects it to be so that the user's other identity information can be found later using PPID+PublicKey or hash(PPID,PubliKey) to do the lookup. When the managed card's STS receives an RST which contains a self-issued SAML token as the user credential, it will extract the PPID and Issuer Public Key from the token and do the appropriate kind of lookup to locate and authenticate the user.
|