[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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? --=_alternative 005C7A8B85256EFA_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">I would suggest these be organized first functionally as that will drive much of the value/limitations discussion. I would group these as:</font> <br><font size=2 face="sans-serif">1. <u>Leverage v1 spec data</u>: Key point here is that v1 defines some data that might have value to leverage.</font> <br><font size=2 face="sans-serif">2. <u>Asserted user identity</u>: How the producer determines it is able to trust this assertion and make any use of it are a couple of interesting questions.</font> <br><font size=2 face="sans-serif">3. <u>Base user credentials</u>: Consumer is passing credentials for use in authenticating the user.</font> <br><font size=2 face="sans-serif">4. This is a variant (i.e. subitem) of #3 that distinguishes where the Consumer gets the credentials it passes. Not sure this is actually within our domain, but am willing to discuss it.</font> <br><font size=2 face="sans-serif">5. Andre, would you say this is also a subitem of #3 or does it offer enough additional functionality that a separate category is appropriate?</font> <br><font size=2 face="sans-serif"><br> Rich</font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Andre Kramer <andre.kramer@eu.citrix.com></b> </font> <p><font size=1 face="sans-serif">08/18/2004 03:42 AM</font> <td width=59%> <table width=100%> <tr> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td valign=top><font size=1 face="sans-serif">"'Michael Freedman'" <Michael.Freedman@oracle.com>, interfaces <wsrp-interfaces@lists.oasis-open.org></font> <tr> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td valign=top> <tr> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td valign=top><font size=1 face="sans-serif">RE: [wsrp-interfaces] Security: mapping identity use cases to pr opogation techniques</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2 color=#000080 face="Arial">For 3 & 4, the password could be either a clear text password or a hashed representation of the clear text password. Both are valid proof of possession but can mean different levels of ability to use back end systems.</font> <br><font size=2 color=#000080 face="Arial"> </font> <br><font size=2 color=#000080 face="Arial">Also, we have a 5, where the consumer passes a SAML assertion. Here we need to decide if the assertion is passed by reference (via an artifact) or included in the protocol and (optionally) signed, or if we use the (complicated) draft SAML profile of WS Security. The version of SAML (1.0/1.1 or draft 2.0) used and the contents of the assertion need to be profiled.</font> <br><font size=2 color=#000080 face="Arial"> </font> <br><font size=2 color=#000080 face="Arial">In addition, we require a way to assert roles to allow a consumer to specify a mapping for an asserted subject. As a fall back, we could just manage user roles out of band, as seems to be suggested by 1-4, but if the model is "trust the consumer" then the only scalable solution is to have the consumer assert both the user identity and her roles.</font> <br><font size=2 color=#000080 face="Arial"> </font> <br><font size=2 color=#000080 face="Arial">Regards,</font> <br><font size=2 color=#000080 face="Arial">Andre</font> <br><font size=2 color=#000080 face="Arial"> </font> <div align=center> <br> <hr></div> <br><font size=2 face="Tahoma"><b>From:</b> Michael Freedman [mailto:Michael.Freedman@oracle.com] <b><br> Sent:</b> 18 August 2004 00:10<b><br> To:</b> interfaces<b><br> Subject:</b> [wsrp-interfaces] Security: mapping identity use cases to propogation techniques</font> <br><font size=3 face="Times New Roman"> </font> <br><font size=3 face="Times New Roman">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:</font> <br><font size=2 face="sans-serif">1. </font><font size=3 face="Times New Roman">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:</font> <br><font size=2 face="sans-serif">1. </font><font size=3 face="Times New Roman">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.</font> <br><font size=2 face="sans-serif">2. </font><font size=3 face="Times New Roman">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.</font> <br><font size=3 face="Times New Roman"><br> 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?</font> <br><font size=2 face="sans-serif">2. </font><font size=3 face="Times New Roman">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). <br> <br> 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. </font> <br><font size=2 face="sans-serif">3. </font><font size=3 face="Times New Roman">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.<br> <br> 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.<br> <br> 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.<br> <br> 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].</font> <br><font size=2 face="sans-serif">4. </font><font size=3 face="Times New Roman">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?</font> <br><font size=3 face="Times New Roman"> </font> <br> --=_alternative 005C7A8B85256EFA_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]