Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Changing AuthNSelfIssuedMaterials

Hey Jim -- long time...
 
The use of that attribute was for a non-Higgins role calculation aspect of the demo.  We could have also done things like AD does (search for all groups that list the member).  We just wanted to show that it's possible to do such a calculation (not proposing to prescribe a particular way in which to do it)
 
Jim

>>> Jim Willeke <jim@xxxxxxxxxxx> 2/7/07 9:05 AM >>>
If you are performing a generic Demo, groupmembership is not a good attribute to be used as it is Novell Specific.
Although LDAP server support an attribute on the user listing the groups their are a member of, it is not generic and even in Novell, using LDAP calls and adding the user to a group may not set the groupmembership attribute on the user.

On AD, the attribute is really a server lookup to see which groups the user is a member of.

--
-jim
Phone: 419.564.7692
Email: jim@xxxxxxxxxxx
IM: jim@xxxxxxxxxxx (on MSN)
IM: jwilleke@xxxxxxxxx (on GOOGLE)
IM: jwilleke (on Yahoo)
IM: jeemster (on AIM)
My LinkedIn: http://www.linkedin.com/in/jwilleke

Jim Sermersheim wrote:
Actually, groupMembership is not operational, but another one being used (GUID) is.  We're currently mapping personalPrivateIdentifier to GUID, and this is why that attibute has to be asked for by name.  We don't wish to continue this practice, but I'll let Daniel speak to the alternative going forward :)
 
Does the STS really *know* about any particular attribute?  Or does it just ask for all that are asked for as claims in the RST?  I didn't think the STS was coded to know about any particular attribute.
 
I guess the way in which the schema gets extended is up to the LDAP directory deployer.  I traditionally favor using auxilliary classes like ou show below, but there is a cost.  That aux class has to be specifically added to any existing person needing these attributes and specifically added when creating a new person which needs them.  Not a bad thing, just something to be aware of.
 
the groupmembership claim is supported by a groupMembership attribute in the directory.  The syntax in our server is DN (1.3.6.1.4.1.1466.115.121.1.12).  If other servers don't support that syntax, another (like Directory String) could be used without negative consequences I believe.  This is multi-valued and holds the names of the groups thaat the subject is a member of.  We are using these values as pat of a roles calculation during an authorization phase.
 
<aside>
When one looks at values of this, one uncovers an inconsistent part of the LDAP CP.  This value contains a name in LDAP DN form, while other methods take names as a short name (not a DN).  We hope to move all name mapping code out of the LDAP CP and into a standalone mapping provider.
</aside>
 
It's easy for us to extend our schema with the extra attributes, and maybe we should move to using an aux class like you suggest.  How would the entropy attribute be used (what process sets it, what process reads it)?
 
And again, I wasn't aware that the STS or LDAP CP had any intimate knowledge of specific attributes like groupMembership.  Where is that code?
 
Jim

>>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/7/07 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.
> 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

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



Back to the top