Hi Greg, Wow - That's what I call a reply :-)
Thanks for all the terrific elaboration. It's really interesting stuff. I would love to ask more questions and first I want to make sure I'm in a position to actually do more than just ask questions, so I'll hold off for a little bit until I have a chance to understand better how something like this fits/complements an ApacheDS roadmap. I'll post back asap. Thanks again, - Ole --- [EMAIL PROTECTED] wrote: > On Nov 30, 8:05pm, Ole Ersoy wrote: > } Subject: Re: Open architecture identity and > authorization efforts. > > > Hi Greg, > > > > Just wanted to see if I understand this part: > > Hi Ole, thanks for the note. My apologies for not > replying sooner, > busy time of the year. > > > >>The derived identities serve as an > identity/label > > for >>an object which > > >>encapsulates information on whether and how to > > >>delivery, vend or > > >>authorize a service. > > > So I have an object. Suppose I express it in > > xml: > > > > <hello> > > <ssn>4325552222<ssn> > > </hello> > > > > If I were to send this to someone, or someone > > were to get it, it could mean something unique > > to them based on rules we have agreed to. > > > > However I may wish to encrypt it first so that > it's > > more compact, faster to read, send, etc. > > > > So I produce a checksum out of it. > > > > The other party also understands the checksum > because > > we shared the information upfront (So they already > > know what it is without decrypting and then > reading > > values, etc). > > > > So now the checksum becomes the derivation of this > > object and it's a nice compact little guy. > > > > And the other party knows what this is, so they > can > > map it to any API call they wish. > > > > If I were to add some info: > > <hello> > > <ssn>4325552222<ssn> > > <buy>sweater</buy> > > </hello> > > > > And produce another checksum...the other side > would > > also understand this because we shared the mapping > > upfront...in other words we knew we would be > talking > > with these objects in the future, so we > > already setup the process for handling it as > > efficiently as possible. > > Very interesting analysis, just a few comments and > clarifications. > This usage scenario is somewhat more in line with > something we refer > to as the Reciprocal Identity Management (RIM) > problem. > > This problem is inherent in federated identity > systems where the > service to be delivered needs to be metered or > authorized. Both > participating parties need to create/manage an > identity for a user. > In addition a system for determining how the user > can access a service > needs to be implemented, at a mininum, at the site > receiving the > identity assertion. > > For the purposes of better understanding the > IDfusion model lets > restrict our thinking to an intra-organizational > model. In this model > there are three entities participating in the > decision of how to > represent an identity and vend the service, they > are: > > 1.) The identity management system. > 2.) The KDC/LDAP server architecture. > 3.) The application. > > In its simplest implementation the IDfusion model > considers that three > identities exist. Two of them are called > fundamental identities and > the third is what is referred to as a derived > identity. The following > nomenclature makes referring to these a bit easier: > > Uii: User identity > > Sii: Service identity > > SIii: Service instance identity (derived identity) > > The SIii is referred to as a derived identity > because it is created by > combining, fusioning if you will, the Uii and Sii > identities. > > The actual identities are represented as n-bit > vectors. Cryptographic > hashes are used for the 'fusioning' process and n > represents the > message size of the hash. In the current reference > implementation > SHA1 is used as the hash so n=160. > > When the identity management system wishes to create > an authorization > for a user to access a particular service the > following formula is > implemented: > > SIii = Hn(Uii,Sii) > > The ASCII representation of the SIii is used to > create a DN which > encapsulates a set of attributes which define how > the service is to > delivered. For simplicity lets consider that the > SIii has only a > single attribute called state which can have the > value of enabled or > disabled. > > The resulting LDIF entry would thus look like the > following: > > SIii=[0-9a-f]m,dc=something,dc=org > state: enabled > > Where [0-9a-f]m is REGEX notation for the ascii > representation of the hash. For n = 160, m = 40. > > The identity management system also publishes the > Uii and Sii objects > in the directory. In each case the hexdecimal > representation of the > 'intrinsic identity' is used to form the terminal > element of the DN. > Lets assume the Uii and Sii also have an attribute > called state. > Lets also assume the Sii has an attribute called > svcname which holds > the name of the service. So in addition to the SIii > object the > following two objects are also in the directory: > > Uii=[0-9a-f]m,dc=something,dc=org > state: enabled > > Sii=[0-9a-f]m,dc=something,dc=org > svcname: LOGIN > state: enabled > > Lets assume an organization is hosting a web > application which is SSL > protected and requests a username and password from > the user. The > application authorizes the user by checking to see > whether or not they > are authorized for the LOGIN service. > > The authorization process consists of the > application checking to find > out if an SIii created from the identities of the > user and service is > in the directory. If it is the attributes of the > Uii, Sii and SIii > are used to refine the authorization decision. > > The process is started by the WEB application > issueing a > ticket-granting request to the KDC. The KDC has > been taught to 'talk' > to the LDAP server and loads the authorization > payload field of the > TGT with the Uii of the user. > > The TGT is returned to the application which then > makes a service > ticket request to the KDC for a principal of the > following form: > > === message truncated === ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
