Re: [higgins-dev] Changing AuthNSelfIssuedMaterials

["Tom Doman" <TDoman@xxxxxxxxxx>]

Right, any hard coded mapping was temporary pending a configurable mapping CP.  Regardless, the LDAP CP can and should still be considered as not knowing anything about any attributes other than the magic it needs to perform with AuthN materials.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 02/07/07 8:37 AM >>>
Oh, I was wrong on one point.  groupMembership *is* hard-coded in the LDAP CP to map to "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groupmembership ( http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groupmembership )".  I had it in my head that this was a configuration item -- which it should be, we're just not there yet.

>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 2/7/07 8:21 AM >>>
Mike,
 
groupMembership is simply a claim that we use in our demo.  We use it in our RP (the media wiki) to determine user roles.  We probably should have used a different URI instead of 
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/groupmembership  It's not really intended to be an extension of the 14 claims established by MS -- but when we were putting together our demo, we weren't sure if it should be a Novell-specific URI either. -- We just didn't know what URI to give it at the time, so we just made a quick (and undoubtedly bad) choice for the demo. -- I assume you are putting together a demo of your own.  Unless your RP needs to ask for a groupMembership claim for some specific purpose, I would just leave it out.
 
In our LDAP schema the attribute is called "groupMembership."  I believe the syntax is DN (distinguished name), and it allows multiple values - Jim can correct me on this if that is wrong.  The list of DNs is the group objects that the containing object belongs to.  It is returned as multiple strings - each one being a DN.
 
Jim and Tom can give further info. about what would need to be done to support gender, website, and entropy attributes - I assume that it is a matter of extending the schema and then providing mappings from the claim URIs to the LDAP attribute names.  Right now all of our name mappings are hard-coded in the LDAP CP, but we are looking at providing a "mapping" context provider that makes it all configurable.
 
Daniel

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/7/2007 6:10 AM >>>
Thanks for getting this change done quickly, I appreciate it.

There are a couple of directory portability conventions I'd like to irn 
out. As with a lot of things, eventually this won't matter - but for the 
short term it does.

Novell has extended the set of claims to include the groupmembership claim 
- Because this is an operational attribute in LDAP, the STS (and LDAP CP?) 
is currently coded to "know" about this claim. Since my code knows about 
it and asks for it I'd like to know how its populated in the LDAP schema. 
(what attribute name, format of values, etc).

Also, the MSFT specs for CardSpace include at least two claims that are 
not typically supported in inetOrgPerson or ePerson: website and gender. 
Additionally, I would like to support a value to be used along with an RP 
specific value (public key?) to provide entropy for User::RP specific key 
pair generation.

I would like us to support these capabilities ASAP. My short term approach 
will be to create a new auxillary objectClass: "higginsPerson" with the 
following attributes:
        cardKeyHash (Multivalue/Directoy String)
        website (Multivalue/Directory String)
        gender (Singlevalue/Directory String)
        entropy (Singlevalue/Octet String)

I am not 100% sure whether Novell is using a pre-existing attribute for 
groupmembership, if not I'll add a multivalued groupMembership attribute 
to this list.
Also, depending on performance issues it might make sense to cache 
generated RP specific key pairs in a multivalued attribute.

Looking for response from Novell on:
        a) what attribute is used to support groupmembership claim?
        b) what needs to be done to the LDAP CP to support website, 
gender, entropy values?

We obviously need to get away from needing to code the CP and STS to know 
about Claim URI to LDAP attribute mapping as soon as we can, but for now 
this is life.

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 02/07/2007 01:03:35 AM:

> The current implementation of this takes a single byte[] value and 
> assumes the attribute name is http://www.eclipse. ( http://www.eclipse./ )
> org/higgins/ontologies/2006/higgins#cardKey
> 
> The caller had to build this byte[] by concatenating (from values in
> the RST) the ppid, public key modulus, and public key exponent.
> 
> The way the LDAP CP implemented this was to simply search for that 
> value, and if a single identity is found then that was the point of 
> authentication. 
> 
> It turns out that at least one LDAP server doesn't allow searching 
> for a binary value (which is what the byte[] caused to be in the 
> search filter), so we had to re-think our implementation.
> 
> After long deliberations, we decided it would be best to make this 
> authN materials be more abstract, and built using the constituent 
> data parts that make up the materials (ppid, public key modulus, and
> public key exponent).  This way the underlying CP can do what's 
> right in terms of it's backing store (we shouldn't write the 
> contract between the CP and it's backing store.
> 
> So, we're proposing to make AuthNSelfIssuedMaterials be made up of 
> these three parts, and the LDAP CP can store and search for the 
> concatenated value as a base64 string.
> 
> The next step (on the subject of proper abstraction) would be to 
> introduce an analogous abstraction for the updating of authN 
> materials.  Because we allow any object to be used as authN 
> materials during context.open, it makes sense to provide an API 
> which can be used to set/update those authN materials.  Previously, 
> I had thought it would be "good enough" to make IdAS consumers use 
> traditional attribute update methods, but it's clear now that this 
> is insufficient.  Some AuthN materials may have a completely 
> different, or even no representation as attributes in the store, and
> it may be impossible to even represent them as attributes such that 
> traditional attribute update methods may be used.  Plus, introducing
> an the authN materials update mechanism decouples the IdAS consumer 
> from any intimate knowledge of how any CP implements support for any
> given AuthN materials.
> 
> I'm not proposing to check in anything yet for this next step right 
> now, just the changes that will allow us to switch to using strings 
> on the back-end store.
> 
> We've already done the first part locally and integrated the three 
> relevant components (STS, IdAS, LDAP CP), we just haven't committed 
> anything yet.
> 
> Jim_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/higgins-dev 

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