Security: mapping identity use cases to propogation techniques

[Michael Freedman <Michael.Freedman@oracle.com>]

     From the discussions we have been having I see 4 possible types/ways/levels 
  for the consumer to pass user [identity] information to the producer.  Each 
  of these 4 types/levels affords the producer a different level of function. 
   My idea is to enumerate these 4 levels, describe what function a producer
  can achieve with this level and then figure out whether this is useful
or   not.  The 4 levels/types are:

1. Consumer passes a UserContext key directly in the WSRP protocol.  As this suggests, this information doesn't pass the user's identitiy, rather a key/representation of this identity that is only useful for distinguishing between other identity keys.  Two types of producers would find this level useful:
1. Producers that use the key to map/establish an application [level] user identity.  I.e the UserContext key allows the producer to distinguish between different consumer users without knowing the particular consumer user identity.  The Producer can use this key to lookup and establish an application level user identity for a variety of purposes; whether to find backend resource credentials or merely to augment/adjust how it behaves/what it displays to this user.  The key here is that this identity only has application level semantics.  The underlying system has no knowledge of a [authenticated] user.
2. Producers that use the key to map to an security context level identity.  I.e. the Producer can use this key to lookup in an internal [application] credential store the user's credentials.  It can then use these credentials to authenticate the user to establish the system level user identity.  In this example, the Producer is [likely] in a different user domain from the consumer and is choosing to use the key to map between the two domains.

Open Question: How realistic is the authentication scenario?  How/Does a system like J2EE allow the application to authenticate a user when its the application that provides the credentials vs. the user itself?


2. Consumer uses WS-Security to pass the Username to a Producer that runs in a shared user domain. Note, we are merely passing the username.  We are neither passing the password or the authentication credentials.  For this scenario, though there is no standard indicating what a WebService stack should do with this information its my understanding that many web stack providers [BEA, IBM, Oracle] have/are planning implementations that allows a [producer] service to be configured in a way that indicates its running in a trusted environment and to accept WSS Username tokens as "user credentials".  I.e. the web stack, in such a configuration, will use the username to establish the security context for the running environment.  Thus both the application [producer] and the system itself sees this user as the current user with whatever roles are granted.  Open question: what I don't know is how far this reaches.  As the Producer/system doesn't have a copy of the authentication token that results from the authentication process the producer/system may not be able to communicate with certain external systems [that require some proof of authentication].  For example, can I get profile data?  Can I even get role information? Am I able to login/runas this user when access a database?Depending on these answers, this scenario may add little to the producer's capabilities over (1).  
   
   One difference between (1) and (2) is in the management of trust.  This scenario seemingly must run in a homogeneous environment where all consumers in that environment are trusted to send correct identities and they all share the user space with the producer.  I.e. its an Admin choice to configure the producer/service this way.  In (1) because its done at the application level the producer decides if/why it trusts the consumer to assert the user context key.  It can vary its behavior on a per consumer basis.  
   
   
3. Consumer uses WS-Security to pass the Username and password to a Producer that runs in a shared user domain.  In this scenario the web service stack receives (presumably) enough information to authenticate the user.  Like (1) I assume there is a progammatic mechanism where this can be done.  So in the end the web service stack would (presumably) authenticate the user, if successful set up the security context, and also attach the authentication key/token (whatever?) in the response (as what, a cookie?) so on subsequent requests from the consumer can use this key/token to bypass the authentication step.
   
   The basic difference between (2) and (3) is that producer environment has the actual proof of authentication vs merely an identity.  That is if/where ever there were limitations in (2), this scenario presumably doesn't have them.  So the value of (3) depends on the limitations of (2).  If there are little to know limitations in (2) then (3) may not be useful.
   
   Note:  I haven't yet determined if web stack providers behave as described in this scenario.  Though I presume this is the standard WSS use case/scenario.
   
   Open Question:  How do web stacks/application servers work from the client side?  Do they allow the client application (consumer) to programmtically set how to pass identity information or is this a per client stub configuration?  I.e. do current implementations limit a consumer to interact with all producers in the same way because its set up declaratively/though configuration?  I am assuming, of course, that there is no "policy" mechanism that the client uses to determine the servers security needs but rather this information is being set up/communicated out of band. [This is my understanding of the curernt state of the standards/web stack implementations].
   
   
4. Consumer uses WS-Security to pass the Username and Password to a Producer that runs in a different user domain.  In this scenario, the consumer provides a credential storing/mapping service to the producer.  The consumer (utilizes a service to) stores producer username/passwords keyed by consumer user identity.  When the consumer calls the producer, the mapped producer username and password are sent using the same WS-Security tokens as (3).  From this point on everything on the producer side is jsut like (3).  The key question here above those inherited from (3) is whether any application servers/web stacks support this from the client side?  I.e. Though I can imagine a web service stack supporting a way to propagate the current user identity do any support this mapping/credential store facility directly or at a minimum expose APIs that allow the client to set the username/password directly?