[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
whether to find backend resource credentials or merely to augment/adjus= t how it behaves/what it displays to this user. The key here is that thi= s identity only has application level semantics. The underlying system h= as no knowledge of a [authenticated] user. 2. Producers that use the key to map to an security context leve= l 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 leve= l user identity. In this example, the Producer is [likely] in a differen= t user domain from the consumer and is choosing to use the key to map bet= ween 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. Fo= r this scenario, though there is no standard indicating what a WebService= stack should do with this information its my understanding that many we= b stack providers [BEA, IBM, Oracle] have/are planning implementations th= at allows a [producer] service to be configured in a way that indicates it= s 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 th= e username to establish the security context for the running environment.= Thus both the application [producer] and the system itself sees this us= er as the current user with whatever roles are granted. Open question: wh= at I don't know is how far this reaches. As the Producer/system doesn't hav= e 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 exam= ple, 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 an= d they all share the user space with the producer. I.e. its an Admin cho= ice 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 consume= r basis. 3. Consumer uses WS-Security to pass the Username and password t= o 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 ca= n be done. So in the end the web service stack would (presumably) authentic= ate the user, if successful set up the security context, and also attach th= e 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 h= as the actual proof of authentication vs merely an identity. That is if/w= here ever there were limitations in (2), this scenario presumably doesn't ha= ve 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 descri= bed 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 cli= ent side? Do they allow the client application (consumer) to programmtical= ly 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 the= re 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 t= o 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-Securi= ty tokens as (3). From this point on everything on the producer side is j= sut like (3). The key question here above those inherited from (3) is whet= her 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 faci= lity directly or at a minimum expose APIs that allow the client to set the username/password directly? = --1__=09BBE468DFD557AF8f9e8a93df938690918c09BBE468DFD557AF Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p>><font color=3D"#000080" face=3D"Arial">Here we need to decide if= the assertion is passed by reference (via an artifact) or included in = the protocol and (optionally) signed,</font><br> <br> How (protocol) the assertion is passed should be consistent, what (form= at) the assertion is should be extensible. So yes SAML can be used if (= 1) want o exclude existing credential/identity formats (2) limit this t= o a SAML protocol <p><br> Anthony Nadalin | work 512.838.0085 | cell 512.289.4122<br> <img src=3D"cid:10__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com"; width=3D= "16" height=3D"16" alt=3D"Inactive hide details for Andre Kramer <an= dre.kramer@eu.citrix.com>">Andre Kramer <andre.kramer@eu.citrix.c= om><br> <br> <br> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:20__=3D09BBE46= 8DFD557AF8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " wid= th=3D"40%"> <ul> <ul> <ul> <ul><b><font size=3D"2">Andre Kramer <andre.kramer@eu.citrix.com>= </font></b><font size=3D"2"> </font> <p><font size=3D"2">08/25/2004 03:04 AM</font></ul> </ul> </ul> </ul> </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""><br> <div align=3D"right"><font size=3D"2">To</font></div></td><td width=3D"= 100%"><img src=3D"cid:30__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com"; = border=3D"0" height=3D"1" width=3D"1" alt=3D""><br> <font size=3D"2">interfaces <wsrp-interfaces@lists.oasis-open.org>= ;</font></td></tr> <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""><br> <div align=3D"right"><font size=3D"2">cc</font></div></td><td width=3D"= 100%"><img src=3D"cid:30__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com"; = border=3D"0" height=3D"1" width=3D"1" alt=3D""><br> </td></tr> <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""><br> <div align=3D"right"><font size=3D"2">Subject</font></div></td><td widt= h=3D"100%"><img src=3D"cid:30__=3D09BBE468DFD557AF8f9e8a93df938@us.ibm.= com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><br> <font size=3D"2">RE: [wsrp-interfaces] Security: mapping identity use = cases to pr opogationtechniques</font></td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img src=3D"cid:30__=3D09BBE468DFD5= 57AF8f9e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt= =3D""></td><td width=3D"336"><img src=3D"cid:30__=3D09BBE468DFD557AF8f9= e8a93df938@us.ibm.com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><= /td></tr> </table> </td></tr> </table> <br> <font color=3D"#000080" face=3D"Arial">5 (using SAML assertions of iden= tity) can be viewed either as falling under (2) or (3) if single-sign-o= n is interpreted as mediating a "credential" but opens up lot= s of specific questions of its own so I would tend towards separating i= t out. 5 "Enabling simple identity Federation"?</font><br> <font color=3D"#000080" face=3D"Arial"> </font><br> <font color=3D"#000080" face=3D"Arial">Regards,</font><br> <font color=3D"#000080" face=3D"Arial">Andre</font><br> <font color=3D"#000080" face=3D"Arial"> </font><div align=3D"center"><h= r width=3D"100%" size=3D"2" align=3D"center"></div><b><font face=3D"Tah= oma">From:</font></b><font face=3D"Tahoma"> Rich Thompson [<a href=3D"m= ailto:richt2@us.ibm.com">mailto:richt2@us.ibm.com</a>] </font><b><font = face=3D"Tahoma"><br> Sent:</font></b><font face=3D"Tahoma"> 24 August 2004 17:50</font><b><f= ont face=3D"Tahoma"><br> To:</font></b><font face=3D"Tahoma"> interfaces</font><b><font face=3D"= Tahoma"><br> Subject:</font></b><font face=3D"Tahoma"> RE: [wsrp-interfaces] Securit= y: mapping identity use cases to propogationtechniques</font><br> <font size=3D"4" face=3D"Times New Roman"> </font><br> <br> I would suggest these be organized first functionally as that will driv= e much of the value/limitations discussion. I would group these as:<fon= t size=3D"4" face=3D"Times New Roman"> </font><br> 1. <u>Leverage v1 spec data</u>: Key point here is that v1 defines some= data that might have value to leverage.<font size=3D"4" face=3D"Times = New Roman"> </font><br> 2. <u>Asserted user identity</u>: How the producer determines it is abl= e to trust this assertion and make any use of it are a couple of intere= sting questions.<font size=3D"4" face=3D"Times New Roman"> </font><br> 3. <u>Base user credentials</u>: Consumer is passing credentials for us= e in authenticating the user.<font size=3D"4" face=3D"Times New Roman">= </font><br> 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 with= in our domain, but am willing to discuss it.<font size=3D"4" face=3D"Ti= mes New Roman"> </font><br> 5. Andre, would you say this is also a subitem of #3 or does it offer e= nough additional functionality that a separate category is appropriate?= <font size=3D"4" face=3D"Times New Roman"> </font><br> <br> Rich<font size=3D"4" face=3D"Times New Roman"> <br> </font> <p> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"32%"><b><font size=3D"2">Andre Kramer &= lt;andre.kramer@eu.citrix.com></font></b><font size=3D"2"> </font> <p><font size=3D"2">08/18/2004 03:42 AM</font><font size=3D"4" face=3D"= Times New Roman"> </font></td><td width=3D"68%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"13%" valign=3D"middle"><div align=3D"ri= ght"><font size=3D"2">To</font></div></td><td width=3D"88%"><font size=3D= "2">"'Michael Freedman'" <Michael.Freedman@oracle.com>,= interfaces <wsrp-interfaces@lists.oasis-open.org></font><font si= ze=3D"4" face=3D"Times New Roman"> </font></td></tr> <tr valign=3D"top"><td width=3D"13%" valign=3D"middle"><div align=3D"ri= ght"><font size=3D"2">cc</font></div></td><td width=3D"88%"><font size=3D= "4" face=3D"Times New Roman"> </font></td></tr> <tr valign=3D"top"><td width=3D"13%" valign=3D"middle"><div align=3D"ri= ght"><font size=3D"2">Subject</font></div></td><td width=3D"88%"><font = size=3D"2">RE: [wsrp-interfaces] Security: mapping identity use cases = to pr opogation techniques</font></td></tr> </table> <font size=3D"4" face=3D"Times New Roman"> </font> <p><br> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"50%"><font size=3D"4" face=3D"Times New= Roman"> </font></td><td width=3D"50%"><font size=3D"4" face=3D"Times N= ew Roman"> </font></td></tr> </table> </td></tr> </table> <font size=3D"4" face=3D"Times New Roman"><br> <br> </font><font color=3D"#000080" face=3D"Arial"><br> 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><font size=3D"4" face=3D"Times New Roman"> </font><font = color=3D"#000080" face=3D"Arial"><br> </font><font size=3D"4" face=3D"Times New Roman"> </font><font color=3D= "#000080" face=3D"Arial"><br> 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 artifac= t) or included in the protocol and (optionally) signed, or if we use th= e (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 b= e profiled.</font><font size=3D"4" face=3D"Times New Roman"> </font><fo= nt color=3D"#000080" face=3D"Arial"><br> </font><font size=3D"4" face=3D"Times New Roman"> </font><font color=3D= "#000080" face=3D"Arial"><br> In addition, we require a way to assert roles to allow a consumer to sp= ecify 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 solu= tion is to have the consumer assert both the user identity and her role= s.</font><font size=3D"4" face=3D"Times New Roman"> </font><font color=3D= "#000080" face=3D"Arial"><br> </font><font size=3D"4" face=3D"Times New Roman"> </font><font color=3D= "#000080" face=3D"Arial"><br> Regards,</font><font size=3D"4" face=3D"Times New Roman"> </font><font = color=3D"#000080" face=3D"Arial"><br> Andre</font><font size=3D"4" face=3D"Times New Roman"> </font><font col= or=3D"#000080" face=3D"Arial"><br> </font><font size=3D"4" face=3D"Times New Roman"> </font><div align=3D= "center"><font size=3D"4" face=3D"Times New Roman"> </font><br> <hr width=3D"100%" size=3D"2" align=3D"center"></div><b><font face=3D"T= ahoma"><br> From:</font></b><font face=3D"Tahoma"> Michael Freedman [<a href=3D"mai= lto:Michael.Freedman@oracle.com">mailto:Michael.Freedman@oracle.com</a>= ] </font><b><font face=3D"Tahoma"><br> Sent:</font></b><font face=3D"Tahoma"> 18 August 2004 00:10</font><b><f= ont face=3D"Tahoma"><br> To:</font></b><font face=3D"Tahoma"> interfaces</font><b><font face=3D"= Tahoma"><br> Subject:</font></b><font face=3D"Tahoma"> [wsrp-interfaces] Security: m= apping identity use cases to propogation techniques</font><font size=3D= "4" face=3D"Times New Roman"> <br> <br>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]