| [higgins-dev] Re: A Higgins integration with cardspace |
|
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 10/28/06 8:45 AM >>>
>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. Not sure either -- I think there have been problems with the listserver.
>> 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. I assumed the RP could know by virtue of there being some DigSig in the posted claims that it came from a "trusted" source, thus in a way being able to sort of differentiate between our STS and a CardSpace one. Maybe I'm deluding myself.
>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. Hopefully Andy (in the CC) is reading, because he's trying to do the same thing using Chuck Mortimore's code as a basis. We should make sure we're not doing the same thing.
>> 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. That's about where we're at too.
>> 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. I assume it depends on *what* the RP is, and how it consumes the signed claims? Some RP implementations, running as inside web app's might be able to use the web-app's infrastructure, but others might just be PHP or something. For the demo, I assume we'll just manually configure it in whatever way we need to.
>> 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. For the first cut of this app, I think we can skip that part. But it does seem like something we'll want soon after.
>> 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. Ah, you're talking about the user credentials, right? I also meant to convey the need for the STS to be able to receive an RST, examine it, and then somehow know which context to open. Maybe there's a table which associates CardID's with contexts. Or maybe the entire context URI is embedded in the CardID (in which case the table isn't needed)
>> 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. Agreed.
>For UserNamePasswordAuthenticate I figure I can just bind to LDAP with the >Username and Password passed in the WSS Header. Oh, maybe so. I should actually look at a WSS header so I can see what you're talking about :)
>> 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 <snip> BTW, I think the schema names have changed a bit.
>My understanding is that I'll need: >a way to get a handle to an IdAS We may have to "hard-code" or at least "hard configure" this until we get the IdAS registry running. In testing, we just instantiate a context factory and have it create the context.
>a way to get a DigitalSubject from the IdAS via Username/Password I can help here. The LDAP provider will soon allow us to create some kind of AuthN identity, and already is capable of producing a DigitalSubject from a name (ok, from an LDAP name, but we can add the ability to use different types of names).
>a way to get attribute values from the DigitalSubject corresponding to the
>Claim URIs above. We may need to do some very minimal claim name mapping, but it should be trivial. We'll talk tomorrow about whether it would be best to do this:
a) above (pre/post)-IdAS
b) as a "mapping" context provider
c) in the LDAP provider as a quick stop-gap.
>> 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. This is more like what I originally was getting at in #4. Daniel was thinking we could use the CardID for this (possibly coupled with some configuration at the STS)
<snip> >> 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. Rather than going straight to LDAP, consider using me or Tom as your IdAS slave -- we'll do whatever it takes to help you integrate with IdAS. In fact, if you want to just point me at the STS code where the integration needs to happen, or where you would do your own "straight to LDAP" thing, I'm more than happy to provide code.
>As for as "b", I suspect this should be discussed with Tony N, Paul T, and
>Mary R. Ok, Tony, Paul, Mary: Is there anything we need to do in order to collaborate on this other than what we're doing (communicating via email, phone, and irc)? Are there resources that are available to be officially focused on any parts of this?
>> 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. We'll still do our #bandit-project meetings, but most of us try to be available on #higgins during work hours.
Jim
|