directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Open architecture identity and authorization efforts.
Date Wed, 06 Dec 2006 19:00:51 GMT
I haven't had a chance to look at the more detailed documentation but  
based on this email and what I want to do with triplesec to integrate  
it with Geronimo I have a question....

Currently triplesec's idea of permission "implies" is equality of the  
"permission string".  This doesn't map well to java permissions where  
often some computation is involved.  For instance a JACC ejb method  
permission might be for all methods on an ejb, or one specific  
method.  A request will generate a permission "Specific"  with one  
specific method, and a role might be granted a permission "General"  
for all methods on that ejb.  To see if we should allow the request  
we evaluate General.implies(Specific), which involves some  
computation involving the contents of the permissions.  Something  
similar goes on for web permissions, where you might be granted  
access to /foo/* except for /foo/private/*.  A specific request will  
have it's url evaluated against these patterns, but the evaluation is  
more compiicated than equality.

 From the discussion below it looks to me a bit as if the permissions  
in IDfusion are stored in an opaque form and authorization decisions  
are based on comparison of this opaque form, which AFAICT would make  
the kind of permission evaluation described above impossible.  So...

Can IDfusion deal with permission objects of this kind, where code +  
data must be executed to determine permissions?  If not is there some  
other way to deal with these infinite sets of specific permissions  
such as those from url pattern matching?

david jencks

On Dec 5, 2006, at 7:44 PM, 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
>> 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:
> 	svc/svcname@REALM
> Where svcname is replaced with the name of the service, in this case
> The KDC has the Uii from the incoming credential and can locate the
> Sii based on the name of the service.  The KDC 'fuses' the two
> identities together to generate the SIii.  The KDC then verifies that
> the SIii is in the directory and if it is a service ticket is
> generated which has the Uii, Sii and SIii identities in the
> authorization payload field.
> The application receives the service ticket and decrypts/unpacks the
> three identities.  It then checks that all three identities are in the
> directory and that the identities are active by virtue of having the
> state: attribute set to enabled.
> This allows an organization three possible avenues for controlling
> whether or not a service is provisioned.  All services can be turned
> off for a user by setting the state: attribute of the Uii to disabled.
> Alternately all requests, regardless of user, to access an application
> which is carrying out authorization via the LOGIN service identity can
> be disabled by setting the Sii state: attribute to disabled.
> The final option is to only disable a particular user from requesting
> access to an application authorized by the LOGIN service.  This would
> be done by setting the state: attribute to disabled of the SIii object
> created by combining the user (Uii) and service (Sii) identities.
> So the actual agreement is between the identity management system and
> the application which is authorizing the user.  The KDC/LDAP systems
> play an intermediary role of determining, at the time of
> authentication, the identity components which are involved in the
> request for services.
> As I mentioned in a previous e-mail one of the security designs
> inherent in IDfusion was to protect the integrity of authorization
> information in the event of a compromise of the directory server.
> This is done by using the HMAC variant of the cryptographic hash used
> in the identity fusioning process.  The SIii formula thus becomes:
> 	SIii = HnKn(Uii,Sii)
> Where Kn is a key derived from the keys associated with the
> svc/svcname@REALM and svc/idfusion@REALM service keys.  I can go into
> the derivation and rationale for that process if there is interest.
> This derivation of the identity fusion formula imposes a cryptographic
> barrier to the creation of SIii identities.  Without access to the
> keys from the KDC an interloper does not possess sufficient
> information to create illegitimate service authorization identities.
> So, thats the general philosophy for how things work.  In many ways
> your analysis was quite correct.  Essentially the SIii is a compact
> representation of the organization's willingness to allow access to a
> service by a particular user.
> The implicit inheritance model of the genetic hash chaining
> methodology allows the Sii object to serve as a 'template' for
> deciding how to authorize a service.  The SIii object can be used to
> override any of the Sii attributes in order to customize service
> delivery on a person by person basis.
>> Thanks,
>> - Ole
> Hopefully the above makes sense and is informative.  I can drill
> deeper on any of these issues if anyone is interested.
> Thanks again for the interest.
> Best wishes to everyone for a productive remainder of the week.
> }-- End of excerpt from Ole Ersoy
> As always,
> Greg
> ---------------------------------------------------------------------- 
> --------
> 			 The Hurderos Project
>          Open Identity, Service and Authorization Management
> "Much work remains to be done before we can announce our total failure
>  to make any progress."
>                                 -- Mike Kelly

View raw message