[higgins-dev] Re: A Higgins integration with cardspace

[Michael McIntosh <mikemci@xxxxxxxxxx>]

Jim,

Thanks for putting this together - comments in-line...

Regards,
Mike

PS: Not sure why, but I've only received this directly form you and not 
via the list.

Michael McIntosh
Java and Web Services Security Group
Security, Privacy, and Extensible Technologies Department
IBM Research

"Jim Sermersheim" <jimse@xxxxxxxxxx> wrote on 10/27/2006 09:19:54 PM:

> We're trying to put together a reference application here that will 
> show some Higgins/cardspace integration.
> 
> We hope to have CardSpace support on a client (in this case IE7 
> either on Vista, or along with .NET 3) communicating with a relying 
> party, where the client will use the Higgins STS and IdAS to answer 
> the RequestSecurityToken sent by CardSpace.

I've gotten IE7 with .NET 3.0 Beta downloaded and working - its a little 
unstable - but suitable for a fingers crossed demo.

> There are a couple benefits of integrating in this way: 1) The BX, 
> ISS UI, and card manager components are already there (for 
> information cards).  2) It shows the use of STS and IdAS as 
> alternate identity providers for managed cards.  Once this is done, 
> we would want to build on it and create an analogous application 
> which works with firefox on other OS's.  These and other forward 
> looking goals are listed here and here . Specifically, we would want
> to get the HBX / ISS / STS integration up to a point where similar 
> functionality can be had using all Higgins components.

I agree this scenario is important, implementable with what we have, and 
goes beyond what we showed at the Berkman Identity Mashup in June (that 
was self asserting STS, this is a "managed card provider" (aka 3rd Party 
Identity Provider)). Unfortunately CardSpace does not allow one to replace 
the self asserting STS and use the CardSpace selector infrastructure, but 
the RP cannot tell the difference between an assertion (self signed or 
managed) generated by our STS and a CardSpace one. The tricky part seems 
to be generating the "managed card" to import into the UI that points at 
our STS, I am working on that now. The current documents are out of date, 
but I've been able to pull a card from a working system and I am using 
that as a template. 

> Specifically, for now we think we need:
> 
> 1) An RP which is a mediawiki installation. We hope to do AuthN and 
> AuthZ using the identity obtained.

For short term testing this weekend I am going back to Kim's Blog - I've 
successfully used the .NET 3 CardSpace implementation to access his blog 
via the CardSpace self asserting STS.

> 2) The STS deployed as a server so it can be pointed at by a managed
> card which has been imported into the client's CardSpace registry. 
> My understanding is that the STS already has this capability.  I 
> haven't yet deployed it as a web service.

I have to figure out how we register the Managed Card STS's signing key 
with the RP (the rough equivalent of Kim's email address verification for 
self signed). Not quite sure how this is done yet. Of course 
current/correct docs would be helpful here, but I can't find them.

> 3) The ability to produce a managed card which is signed by and 
> points to the STS (we hope to start with some code Chuck has for 
> creating this, but it would be good to know if the STS already has 
> some of this capability).

I am almost done with a command line version of this, will commit this 
when its working (this weekend hopefully).
Longer term we'll need a UI at the Managed Card Provider (IP STS) that 
allows one to register and download a card - not sure when/if I'll have 
time for that.

> 4) A way for the STS to associate the information passed in the RST 
> with a higgins context / user.  There may already be something like 
> this in the STS framework, not sure.

I *THINK* CardSpace supports four ways to do this via a WSS header - 
UsernameToken, X.509Token, KerberosToken, and SelfSignedSAML.
The card itself contains the specifics - e.g. "
<UserNamePasswordAuthenticate><Username>mikemci</Username></UserNamePasswordAuthenticate>".
I'll soon see once I get it to accept my card.

> 5) A way to convey the user's credentials (in this case ldap 
> name/pw) to the STS such that it can be used to open the Higgins 
> context.  This can be gathered by the CardSpace selector, and I 
> assume can be passed securely in the RST.

We should discuss how this should work in general - and then for specific 
forms of #4 above - and others.
For UserNamePasswordAuthenticate I figure I can just bind to LDAP with the 
Username and Password passed in the WSS Header.

> 6) Integration between the STS and IdAS.  Need to be able to read 
> specific attributes of a DigitalSubject from IdAS.

Yes, I suspect the Valery's code may be helpful here, but need to take a 
closer look.
The CardSpace will pass the STS some subset of the following claim URIs:
http://schemas.microsoft.com/ws/2005/05/identity/claims/givenname
http://schemas.microsoft.com/ws/2005/05/identity/claims/surname
http://schemas.microsoft.com/ws/2005/05/identity/claims/emailaddress
http://schemas.microsoft.com/ws/2005/05/identity/claims/streetaddress
http://schemas.microsoft.com/ws/2005/05/identity/claims/locality
http://schemas.microsoft.com/ws/2005/05/identity/claims/stateorprovince
http://schemas.microsoft.com/ws/2005/05/identity/claims/postalcode
http://schemas.microsoft.com/ws/2005/05/identity/claims/country
http://schemas.microsoft.com/ws/2005/05/identity/claims/homephone
http://schemas.microsoft.com/ws/2005/05/identity/claims/otherphone
http://schemas.microsoft.com/ws/2005/05/identity/claims/mobilephone
http://schemas.microsoft.com/ws/2005/05/identity/claims/dateofbirth
http://schemas.microsoft.com/ws/2005/05/identity/claims/gender
http://schemas.microsoft.com/ws/2005/05/identity/claims/privatepersonalidentifier

My understanding is that I'll need:
a way to get a handle to an IdAS
a way to get a DigitalSubject from the IdAS via Username/Password
a way to get attribute values from the DigitalSubject corresponding to the 
Claim URIs above.

> 7) An IdAS context provider (we plan to use the LDAP provider to start 
with).

I guess I am wondering how the additional "context" information 
could/would be conveyed from selector to STS.
Obviously CardSpace will not provide that - so for a demo there will need 
to be a default and an assumption that there is a 1:1 mapping from 
DigitalSubject:Context.

> 8) A way to turn the DigitalSubject attributes into claims for the 
> token to be returned (we'll assume no name or value mapping needs to
> occur for this app)

Good ;-)

> 9) The STS needs to wrap the produced token as a SAML assertion and 
return it.

Only work to do here that isn't done is to sign with STS key rather than 
user's key.
 
> It would be good to know: a) what of the above is already done or 
> being actively worked on,  b) who is able to and interested in 
> collaborating on any of the points above.

On 'a', I am working on 2-9. Although I am weak in the area of 
IdAS/ContextProvider, and may go straight to LDAP as an intermediate step.
As for as "b", I suspect this should be discussed with Tony N, Paul T, and 
Mary R.
 
> Oh yeah, we're hoping to have this done by Dec 2.  To facilitate 
> collaboration, we will have 15 minute meetings every Tue-Thu at 11am
> MDT (11am MST after Oct 29). These will take place on the 
#bandit-project
> IRC chat channel at irc.freenode.net.

I prefer to coordinate through the #higgins IRC channel.

> 
> Jim