directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject Re: Open architecture identity and authorization efforts.
Date Wed, 06 Dec 2006 04:05:16 GMT
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


--- greg@enjellic.com 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

Mime
View raw message