[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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?
------_=_NextPart_001_01C484F6.DBEFCC3A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40";>
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:navy;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:31852652;
mso-list-template-ids:685114264;}
@list l1
{mso-list-id:243883065;
mso-list-template-ids:1921911922;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
-->
</style>
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dnavy>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>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.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></=
p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Andre<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>=
<div>
<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>
<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>
</span></font></div>
<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Michael Freedman
[mailto:Michael.Freedman@oracle.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 18 August 2004 =
00:10<br>
<b><span style=3D'font-weight:bold'>To:</span></b> interfaces<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> =
[wsrp-interfaces]
Security: mapping identity use cases to propogation =
techniques</span></font><o:p></o:p></p>
</div>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>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:<o:p></o:p></span></font></p>
<ol start=3D1 type=3D1>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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:<o:p></o:p></span></font></li>
<ol start=3D1 type=3D1>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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.<o:p></o:p></span></font></li>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:
auto;mso-list:l0 level2 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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.<o:p></o:p></span></font></li>
</ol>
</ol>
<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:
12.0pt;margin-left:36.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><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?<o:p></o:p></span></font></p>
<ol start=3D2 type=3D1>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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. =
<o:p></o:p></span></font></li>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt;
mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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].<o:p></o:p></span></font></li>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo1'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>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?<o:p></o:p></span></font></li>
</ol>
<p class=3DMsoNormal style=3D'margin-left:72.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
------_=_NextPart_001_01C484F6.DBEFCC3A--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]