[higgins-dev] [IdAS] authN/authZ issues

[Greg Byrd <gbyrd@xxxxxxxx>]

[If you don't want to read the following long message, here's the 
spoiler:  I think that Object is the correct type for the identity 
parameter in Context.open.]


My action item from the last phone meeting was to investigate the 
authentication and authorization mechanisms for providing Context data 
to a consuming service (which we will call the "client").  Note that 
this client is likely to be an ISS or an STS, rather than a human user.  
The main subject of debate is the "identity" parameter for the 
Context.open call -- is there a better type than "Object", or can we at 
least provide guidance to the client about what types are likely to be 
supported?


First, let me emphasize that any code dealing with this issue will be 
written by the Context Provider (CP), who installs code that implements 
IContextFactory and IContext interfaces.  This means that the IdAS API 
should be neutral in terms of the authN/authZ mechanisms for gaining 
access to the Context.


Second, I want to identify the four entities involved in delivering 
attribute data to the client -- the IdASRegistry service, the 
ContextFactory, the Context, and the DataSource.  My expectation is that 
clients will access the IdASRegistry first, in order to locate a Factory 
that can service a particular Context.  Let's use the term "DataSource" 
to denote the actual source of attribute information.  The job of the 
Context is to mediate between one or more DataSources and the client.  
(A DataSource could, in fact, be another Context or another IdAS 
service, etc., but we'll simply the discussion by assuming that the 
DataSource is an LDAP directory, file, or database.)


As Raj pointed out, there are two scenarios (passthrough and delegate) 
that describe the authN/authZ relationship between the client and the 
DataSource. 


PASSTHROUGH SCENARIO

In the "passthrough" scenario, the client is directly authorized to the 
DataSource.  In other words, the client must provide identity 
credentials to satisfy the policy of the DataSource, and IdAS stays out 
of the way.  The CP's job is to collect this policy information and 
convey it to the client via Context.getPolicy. 

Note that different Contexts created by a single Factory may have 
different policies and different types of credentials required.  In the 
fully dynamic case, the CP will not know ahead of time what type of 
identity will be required.  In other cases, the policy and identity type 
will be hard-wired into the code.


DELEGATE SCENARIO

In the "delegate" scenario, the client will be authorized by the IdAS 
service itself, which will then take responsibility for any 
authorization needed to access the DataSource.  This could be done 
through a "connector" that knows how to map client credentials to those 
needed by the DataSource, or it could enlist the aid of an STS to 
transform client credentials into DataSource credentials.

In this case, the policy is provided by the Factory, as it will be the 
same for every Context.  (Should the client use ContextFactory.getPolicy 
for this?  I propose that we instead have Context.getPolicy return the 
right thing, whether it is imposed by the Factory or the DataSource.  
The client has one place to go, and it doesn't really care where the 
policy comes from.)


CLIENT-SIDE CODE

So what is client code supposed to do, given such flexibility?

In current practice, the mechanisms are hard-wired (or configurable), so 
the client already knows what authN/authZ mechanisms are 
supported/required.  We can presume that this will be the cases in many 
instances in the near future.  In this case it's the client's 
responsibility to create the right type of object to pass into 
Context.open.  If it passes something that can't be handled, the Context 
will throw an exception.

In a more dynamic case, the client would getPolicy, parse the supported 
token types, and then create one (probably with the help of an STS). 

I don't think we want to pass in a javax.security.auth.Subject, because 
it's JAAS-specific and doesn't always translate to J2EE.  I don't think 
we want to create an interface or abstract class of our own, because all 
different kinds of tokens could implement this, so there's no real 
information provided to the client that would help it decide which of 
these types to instantiate.  We could have a Context.getIdentityClass 
method, but how is that different than getPolicy?  The client still 
needs to know how to instantiate the class properly, and there might be 
multiple acceptable token types. 

This leads me to conclude that Object is the best we can do, in order to 
remain neutral about the underlying mechanisms.