Issue 167
From: Marc Goodner
[mailto:mgoodner@microsoft.com]
Sent: Wednesday, March 12, 2008 4:04 PM
To: ws-sx@lists.oasis-open.org
Subject: [ws-sx] New Issue: Missing element for requesting a security
token to act as a different identity
PLEASE DO NOT REPLY TO THIS
EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will
notify the list when that has occurred.
Protocol: ws-trust
http://docs.oasis-open.org/ws-sx/ws-trust/200802/ws-trust-1.4-ed-01.doc
Artifact: spec / schema
Type: design
Title: Missing element for requesting a security token to act
as a different identity
Description:
In the current WS-Trust
specification a requestor can ask for a token to be issued for somebody else
via the wst:OnBehalfOf element. The specification also provides wst:DelegateTo
element that allows a requestor to ask for a token that contains information
about the requestor but is to be used by somebody else.
However, the current
specification does not allow the requestor to ask for a token for itself that
would allow it to act as somebody else. The proposal is to add a new element to
section 9.3 that adds support for this scenario to the WS-Trust specification.
Case
1:
Client C requests a token to access Server S1
C
requests a token from STS (reached via P) to authenticate to S1
·
C
<--> P uses regular RST
·
P
<--> STS uses RST with OnBehalfOf=C basically routing C’s
request to STS
·
Proof
token is encrypted for C
·
C
presents authentication token to S1
Case
2:
Client C is communicating with Server S1 that needs access to Server S2. Server
S1 access to Server S2 must prove the request is for Client C. Client C
provides a delegation token to Server S1 to prove Server S1’s request to
Server S2 is for Client C.
C
requests a delegation token from STS (reached via P) that delegates some rights
to S1 (to obtain service from S2)
·
C
<--> P uses RST with DelegateTo=S1
·
P
<--> STS uses RST with OnBehalfOf=C and DelegateTo=S1
basically routing C’s request to STS
·
Proof
token is encrypted for S1
·
C
presents its own authentication token as well as the delegation token to S1
·
S1
presents the delegation token from C to S2
·
Optionally
S1 presents its own authentication token to S2
Case
3:
Client C is communicating with Server S1 that needs access to Server S2. Server
S1 access to Server S2 must prove the request is for Client C. Server S1
requests a delegation token STS to prove its request to Server S2 is for Client
C.
S1
requests a delegation token from STS (reached via P) to act as C (to
obtain service from S2)
·
C
presents authentication token to S1 (for example, the output of Case 1)
·
S1
<--> P uses RST with ActAs=C
·
P
<--> STS uses RST with OnBehalfOf=S1 and ActAs=C basically
routing S1’s request to STS
·
Proof
token is encrypted for S1
·
S1
presents the delegation token from STS to S2
·
Optionally
S1 presents its own authentication token to S2
The
patterns for case 2 and 3 are only different in who requests the delegation
token – C obtains it and hands it to S1, or S1 gets it directly. As it
stands today we don’t have a way to differentiate between case 2 and 3
using Trust, we’re missing ActAs. Below is a proposal for adding
ActAs to Trust.
Related issues:
None.
Proposed Resolution:
Insert the following after
line 2595 in section 9.3
<wst:ActAs>...</wst:ActAs>
Insert the following after
line 2602 in section 9.3
/wst:RequestSecurityToken/wst:ActAs
This
OTPIONAL element indicates that the requested token is expected to contain
information about the identity represented by the content of this element and
the token requestor intends to use the returned token to act as this identity.
The identity that the requestor wants to act-as is specified by placing a
security token or <wsse:SecurityTokenReference> element within the
<wst:ActAs> element.