[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Hard-coded claims in the STS
|
If we can agree that this will be the behavior - and that no operational
attributes with be used by the LDAP CP that the LDAP CP does not itself
know to always ask for, then I'm happy and we can kill this thread.
higgins-dev-bounces@xxxxxxxxxxx wrote on 02/07/2007 02:28:03 PM:
> For this discussion, PPID is not a good example of an operational
> LDAP attribute. Yes, I know, we made it one in the demo by mapping
> it to the GUID attribute, but that was incorrect. When PPID is
> requested as a claim, it must be handled in a special way by the
> STS. The correct thing for the STS to do is to generate a PPID that
> is unique for the SelectedInfoCard+RP (note: it must always generate
> the same PPID for that SelectedInfoCard+RP). There are several ways
> the STS could do this, but CardSpace gives some assistance.
> CardSpace inserts a <ClientPseudonym> element in the RST message.
> The element contains a PPID that is unique for the
> SelectedInfoCard+RP, as illustrated below:
>
> <ic:ClientPseudonym>
> <ic:PPID>MIIEZzCCA9CgAwIBAgIQEmtJZc0=</ic:PPID>
> </ic:ClientPseudonym>
>
> The simplest thing for the STS to do is to simply return that PPID
> as the value for the requested PPID claim. In that case, it would
> not call IdAS to request a ppid attribute. -- Of course, the STS
> could opt to ignore the <ClientPseudonym> element and generate its
> own PPID - which is fine - as long as it is unique per InfoCard+RP,
> and it always generates the same value for a given InfoCard+RP.
>
> Daniel
>
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 2/7/2007 11:22 AM >>>
> Mike,
>
> With respect to the LDAP CP, I think we're down to one issue (in my
> mind, correct me if I'm wrong). That is the fact that JNDI will not
> return operational attributes unless they are specifically
> requested. I probably just don't understand all the use cases but
> I'm not sure that fact is really an issue yet. Even if it is, the
> LDAP CP can be configured to hide this from the STS by always
> requesting required operational attributes. However, I'm not sure
> any are actually required that shouldn't be being requested already as
claims.
>
> What is the claim in question? http://schemas.xmlsoap.
> org/ws/2005/05/identity/claims/privatepersonalidentifier? If we
> want that claim, shouldn't we ask for it specifically? If so,
> there's no problem. In the future, the mapping provider is
> configured to map that to an attribute appropriate for the enclosed
> CP. Currently, the LDAP CP does it hard codedly for itself and it
> gets mapped to an operational attribute. Now, if there are claims
> that should always be fetched, regardless of what claims were
> requested, the mapping CP or even the LDAP CP could be configured to
> always get it. However, I don't understand that there's a use case
> for this so maybe that's what I need clarified.
>
> Tom
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 02/07/07 10:14 AM >>>
> Jim,
>
> The architecture of the STS intends to separate the acquisition of the
> Subject Context from the Token Issuance - Openning a context should not
> require knowledge of which claims are eventually going into the token.
> However, for the LDAP CP there is currently an issue with respect to the
> "operational" attributes needing to be specifically asked for when the
> context is openned. I am hoping that eventually this CP specific
> requirement will be removed or at least hidden from the STS.
>
> In reality the Card specifies which claims are supported and the STS
> generates the Card so the STS knows in advance (at least at the point it
> gens the card) which claims it will support. I will make this a
> configurable item soon (at least for short term) and allow the generated
> cards to use the same list of claim types.
>
> Thanks,
> Mike
>
> Michael McIntosh
> Java and Web Services Security Group
> Security, Privacy, and Extensible Technologies Department
> IBM Research
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 02/07/2007 10:47:53 AM:
>
> > Mike, I can see in RSTFromAxis1xRST where the STS is asking for
> > groupMembership (along with all other known claims). Shouldn't it
> > just ask for the claims being asked for in the RST? What happens
> > when the RST contains other claims not in this array (alClaims)?
> > Managed cards can cause any arbitrary claim to be present in the RST
> > can't they?
> >
> > Jim
> >
> > >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 2/7/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". 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.
> > > 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
>
> _______________________________________________
> 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
