[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Hard-coded claims in the STS
|
Daniel - you and I agree - I was only trying to get past the issues with
ppoid - if your solution works for everyone then I no longer have a
problem and I an now go back from this:
java.util.ArrayList<java.net.URI> alClaims = new
java.util.ArrayList<java.net.URI>();
alClaims.add(consts.IC_GIVEN_NAME);
alClaims.add(consts.IC_SURNAME);
alClaims.add(consts.IC_EMAIL_ADDRESS);
alClaims.add(consts.IC_STREET_ADDRESS);
alClaims.add(consts.IC_LOCALITY);
alClaims.add(consts.IC_STATE_OR_PROVINCE);
alClaims.add(consts.IC_POSTAL_CODE);
alClaims.add(consts.IC_COUNTRY);
alClaims.add(consts.IC_HOME_PHONE);
alClaims.add(consts.IC_OTHER_PHONE);
alClaims.add(consts.IC_MOBILE_PHONE);
alClaims.add(consts.IC_DATE_OF_BIRTH);
alClaims.add(consts.IC_GENDER);
alClaims.add(consts.IC_GROUP_MEMBERSHIP);
alClaims.add(consts.IC_PRIVATE_PERSONAL_IDENTIFIER);
IDigitalSubject digitalSubject = context.getSubject(strCUID,
alClaims);
To this:
IDigitalSubject digitalSubject = context.getSubject(strCUID);
higgins-dev-bounces@xxxxxxxxxxx wrote on 02/07/2007 02:04:30 PM:
> Mike,
>
> I don't think it is a good idea for the STS to "know in advance"
> what claims will be requested. I know we are assuming that since
> the STS needs to generate the managed card, it is a straightforward
> thing for it to "know in advance" what claims will be requested.
> One could even argue that it is necessary for it to know in advance.
> However, I think it is too limiting to state that a particular
> deployment of the STS should only being able to service one and only
> one kind of managed card with a pre-specified set of claims. I can
> see use cases where a company might want to deploy a single STS that
> is used for multiple kinds of managed cards, each of which requests
> an entirely different set of claims. If you pre-determine the set
> of claims an STS will return based on the assumption that an STS
> handles only one kind of managed card, you eliminate this use case.
> We get our greatest flexibility when the STS simply asks IdAS for
> the claims that are requested in the RST. This should be the case
> whether the claims are the 14 specified MS for use in personal
> cards, or other claims specified by a specific vendor in a managed
> card. To the STS there should be no difference and no special
> handling of the MicroSoft 14 versus others. NOTE: The PPID claim
> requires special handling - but that is a separate discussion.
>
> Daniel
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/7/2007 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
