| Re: [higgins-dev] Hard-coded claims in the STS |
|
Sorry if this comes across as redundant, but I'm still not sure why it's done this way.
At the point of acquisition of the Subject Context, don't we have the list of requested claims? This list could be much smaller that the sum total of all claims that were known to the STS when the card was issued. In fact, a card issued at T1 might be based on a different configuration of claims than a card issued at T2. I'm not sure why the STS needs to be configured to know about claims at card-generation time (not that it's unbelievable), but are we setting things up such that this list can't change over time?
Asking for all known claims can turn into a performance problem as well. Wouldn't it be better to ask for only the claims requested in the RST -- rather than all known claims?
Jim
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/7/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 |