Re: [higgins-dev] Using self-issued card as AuthN method for managed car

[Anthony Nadalin <drsecure@xxxxxxxxxx>]

Bad bad bad, why not just give it root ? I'm still at a loss of what you are trying to do here.

The Content should have enough policy to tell the STS where to go to get a token, the STS goes and gets the token and then presents this to the context, the context may in turn us the "in house" STS or may use an other STS to validate and then if good will do the open

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Jim Sermersheim" <jimse@xxxxxxxxxx>

"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

12/20/2006 12:39 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	<higgins-dev@xxxxxxxxxxx>
cc
Subject	Re: [higgins-dev] Using self-issued card as AuthN method for managed card

For a simple proof of concept, we were thinking of configuring the STS/CP to do the following when dealing with a card of this nature:
 
- STS uses a configured "super-user" identity to open the context.
- STS uses IContext.search(filter) to locate the DS which matches for PPID=<ppid value of the ClientPseudonym in the RST>.   Remember that this PPID was generated for the unmanaged card as if the STS were the relying party.
- Using this DS, the STS continues as it previously has.
 
This is just one way of doing it, but it seems like a fairly simple first step.
 
Jim


>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 12/20/06 11:28 AM >>>
All, Daniel put this together before leaving on Christmas break.  It's full of very useful information.   We also have talked about a fairly simple solution in terms of integration with the LDAP CP for an initial proof of concept implementation.  Daniel has also added a way at the bottom of https://wag.bandit-project.org/index.php?option=createinfocard&action="">

to create a managed card using the ppid of a self-issued card for AuthN.
Jim

>>> Daniel Sanders 12/15/06 9:39 AM >>>
All,

I said I would write up my understanding of PPIDs (privatepersonalidentifier) and how it works with CardSpace. Here is my attempt at it.

General Information About PPID

When a card (either managed or unmanaged) is created in CardSpace, a "master key" is associated with the card. The master key is simply random bits - entropy. The master key has several purposes: 1) it is used to generate a public/private key pair for the card, and 2) it is used in the generation of a PPID for the card whenever one is requested.

A card's PPID is "site-specific." It is computed as needed. It will be different for every relying party the card is selected for. When a relying party requests PPID in its claims, CardSpace uses the subject name in the certficate presented by the relying party to construct the PPID. More precisely, the identifier is computed as a function of the organization name ("O") and any optional location ("L", "S", "C", and "DC") attributes present in the subject name of the certificate.

PPID is intended to represent a pseudonym for a user at a given relying party. It has the privacy characteristic that the PPID for a user at two different relying parties is guaranteed to be different such that they cannot be used as the basis for collusion.

For unmanaged cards, the PPID is generated by the STS that is internal to CardSpace. For managed cards, the external STS the card points to must be able to generate the PPID claim with the same privacy characteristic. Data will be passed to the STS in the RST (Request for Security Token) that will allow the STS to generate an appropriate PPID value.
To enable an STS that supports the PPID claim to be able to always produce a consistent claim value, Windows CardSpace includes the extension element ic:ClientPseudonym/ic:PPID in the RST request, illustrated below:
<wst:RequestSecurityToken>
<ic:ClientPseudonym>
<ic:PPID>MIIEZzCCA9CgAwIBAgIQEmtJZc0=</ic:PPID>
</ic:ClientPseudonym>
...
</wst:RequestSecurityToken>
The <ic:PPID> element contains the result of applying a hash function to a relying party identity and optional user-supplied entropy to produce an opaque, yet consistent, reference for the relying party. This value must be used as the basis for generating a PPID claim that is sent back to the RP in the security token. The STS may use this value as is or as an input seed to a custom function to derive a value for the PPID claim.

Using An Unmanaged (Self-Issued) Card As The Authentication Method For a Managed Card

A managed card may specify one of four authentication methods - or types of user credentials - for authenticating to the IdP. These are: 1) Username/password, 2) Kerberos v5 Credential, 3) Smartcard based X.509 Certificate Credential, and 4) Self-issued Token Credential. When a card is selected, the appropriate authentication materials are sent to the STS in the RST. For username/password, the user will be prompted to enter a username and password before sending the RST.

The reasons we are interested in the Self-issued Token Credential are because it does not require the user to enter any credential information, which would allow us to support single sign-on (SSO). The Kerberos credential and the X.509 Credential may or may not require the user to enter information - we don't know exactly how they work at this point. Of the three, self-issued token credential seems to be the simplest in concept to implement, and perhaps the easiest for a user to work with. It works as follows:

1) The <UserCredential> element in the managed card contains a <SelfIssuedCredential> child element, which in turn has a <PrivatePersonalIdentifier> child element that holds a PPID. The PPID references an unmanaged card. Recall that PPID is "site-specific." In this case, the "site" (or relying party) is the STS pointed to by the managed card. Thus, the PPID should be the one that is generated for the unmanaged card as if the STS were the relying party. That makes perfect sense, because the STS is, in fact, the relying party that will receive authentication material - the PPID of the unmanaged card. It is as if the STS requested a PPID claim and the user selected the unmanaged card to satisfy that claim.
The XML in the managed card looks like this:
<ic:UserCredential>
<ic:SelfIssuedCredential>
<ic:PrivatePersonalIdentifier>base 64 PPID</ic:PrivatePersonalIdentifier>
</ic:SelfIssuedCredential>
</ic:UserCredential>
2) When the managed card is selected by a user, the unmanaged card's PPID and public key is sent to the STS in the RST as the authentication material.

3) The STS uses the PPID+public key to "lookup" the user account and request the attributes needed to create a security token that will be sent back to the relying party. -- This is the part that we need to figure out how to do in our LDAP CP.

Well, I think that is all I am going to write up for now. I will attempt to do a drawing and send that out later.

Daniel_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev