| Re: [higgins-dev] Questions about LDAP ObjectIds |
|
I added higginsPerson as a placeholder. I was thinking it would be an auxiliary class which list various attributes that are used in an interoperable way by applications or context providers written to the higgins interfaces. For example, it could name attributes which are surfaced as metadata in a higgins context.
Maybe I should remove it because there's no existing use-case for it yet.
>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/19/07 6:19 PM >>> Tom, Thanks. This helps. My concern was the over the reserved OID for higginsPerson, which implied to me that an LDAP higginsPerson object was required by an LDAP CP. I am glad to see that inetOrgPerson maps to the Higgins class. The second part of my post is rooted in my ignorance about how CardSpace works. So if I were to use Active Directory as the backend store of my LDAP CP, I would also need to extend the Active Directory schema to include "cardSpacePerson" and "cardSpaceKey"? David David Kuehr-McLaren IBM Tivoli Security 919.224.1960
David, Did you get my reply to Paul's development call meeting minutes? I'll include that here in case you weren't on the higgins-dev list yet and then answer your questions. Paul's Notes of OIDs: "1. Object Identifiers ---------------------- See [1] BrianC: these are needed for object classes and types in LDAP and IANA is the standards organization David: IBM has a requirement Paul: officially we only specify higgins.owl Mike: yes, but unofficially there is a requirement to use specific schemas to use the LDAP CP. Right now, in order for it to work there is some mapping that needs to occur. You now have the ability to do this mapping in configuration files (though explaining this to customers is not easy). Brian: there are a couple of scenarios. One is a demo/test scenario. The other is more production scenario where one typically can't make any changes to the schema. David: My concern that by registering object ids we're making a schema statement about what needs to be there to support IdAS. Mike: Currently we do have some restrictions. We're moving away from those restrictions. Though as Brian pointed out, we'd probably like to have a light-weight deployment scenario." My response: "On #1, Object Identifiers, I should add a comment. I'm not sure what "specific schemas" are required that Mike is referring to other than what we've chosen to do in the JNDI CP to support AuthNSelfIssuedMaterials but that doesn't require any mapping. Anyway, supporting that is what has precipitated the creation of two OIDs in our Eclipse allocated arc. I'd be happy to further detail this if that's what the discussion was centered around but the comments aren't very specific. I assume that maybe Mike meant that for the CardSpace claims, there's a required mapping that can be done via a configuration file. But, while this is true, I'm not sure what concern is trying to be resolved. That's why I assumed maybe the discussion was due to the two OIDs we just added for the SelfIssuedMaterials. Based on what David said, I'd expect that's what he was referring to. I think I need to clarify some things here but I need to make sure the concern is clearly articulated. Anyone?" So, I think you've given me some clarification with your questions here but let me know if there's more to clear up based on the meeting call: I don't know that we'll have a need for a higginsPerson, Jim added that one and I'm not sure what he had in mind there. I did some work on mapping LDAP schema to the Higgins ontology last year which ultimately mapped inetOrgPerson to the base Higgins class. I've attached the output that the JNDI CP produced back last year. Since we fiddled with the mapping mechanism in the JNDI CP it's not quite right at the moment but that attached file will give you the idea. A nice graphical OWL editor will show you how "inetOrgPerson", for example, comes out. The "cardSpacePerson" and "cardSpaceKey" schema elements are required to be added to any LDAP directory that will back the Higgins JNDI CP in order to support the SelfIssuedMaterials authentication method prescribed thereby. Any LDAP entry backing a self-issued card must be given the same hash (a non-reversable hash for security) that the SelfIssuedMaterials prescribes (ie. hash of PPID + Public Key Modulus + Public Key Exponent), and have it stored on the backing entry through the use of the cardSpacePerson auxiliary class and cardSpaceKey attribute. I guess we need to publish this hash and the entire mechanism for our cardSpace support through an backing LDAP store. Though a similar mechanism could be used against any backing store. Does this help? Thanks, Tom >>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 4/19/2007 4:30 PM >>> Thanks all for entertaining my LDAP OIDs questions on the status call today. I have a couple of more questions. Do we know we need an OID for higginsPerson? I was hoping that a base Higgins class could be mapped to inetOrgPerson. Does anyone know if Microsoft needs to add any schema to Active Directory equivalent to "cardSpacePerson" and "cardSpaceKey"? David David Kuehr-McLaren Identity Management Integration IBM Tivoli Security dkuehrmc@xxxxxxxxxx 919.224.1960 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |