directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Open architecture identity and authorization efforts.
Date Wed, 06 Dec 2006 03:44:45 GMT
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

	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

The resulting LDIF entry would thus look like the following:

	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:

	state: enabled

	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:


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,

			 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