Re: [higgins-dev] Changing AuthNSelfIssuedMaterials

[Michael McIntosh <mikemci@xxxxxxxxxx>]

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.
> 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