[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue 162: no way to specify the policies for renew and cancel
So let’s start with a basic SCT baseline for this discussion: ·
The policy for S (SPol) describes the requirement for a SCT
token and (optionally) indicates that the issuer is “STS”. ·
The policy for STS (StsPol) describes the requirements that it
requires for authentication. ·
The client issues an RST to the STS that conforms to StsPol and
obtains an SCT which it uses to communicate with S in accordance SPol. ·
The policy for renew and other operations are defined specific
to the STS actions within StsPol. Given that baseline, let’s consider the scenario where S hosts
the STS itself but uses a separate port. In this scenario, the flow is the
same except that both S and STS are in the same service but using separate WSDL
ports. The final scenario is where S hosts the STS itself and uses the
same WSDL port for both the STS and the service S. In this case there are
two different kinds of message arriving at the port which have different
security policies (SPol and StsPol). In this case the policy on the WSDL
port could be described as: ·
When the action is an STS action use StsPol ·
When the action is a S action use SPol As a simplification for this last scenario the bootstrap
semantic was defined so that you could use a notation like Bootstrap(x) where
“x” defines the policy for Action=STS-Issue. This is really just a
shorthand mechanism for the generalized conjunctions of WS-Policy. In this scenario if S wanted to have policy for “STS-Renew” it
simply needs to use the generalized WS-Policy mechanism that associates policy
with the STS-Renew action. From: Marc Goodner
[mailto:mgoodner@microsoft.com] Issue 162 From: Corinna Witt
[mailto:cwitt@bea.com] 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-sp http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.pdf Artifact: spec Type: design Title: No way to specify the policies for
WS-SecureConversation renew and cancel Description: WS-SecurityPolicy currently allows to define the
WS-SecureConversation bootstrap policy, but there is no way to specify the
policies for renew and cancel. WS-Trust and WS-SecureConversation don't talk
about how to agree on policy for this either (they just talk about some general
requirements for such a policy). The following proposal is intended to start
discussion on a solution that would eliminate the need for out-of-band
agreements. Proposed Resolution: Add the following to the chapter "5.4.7
SecureConversationToken Assertion" of WS-SecurityPolicy (additions in
bold): <sp:SecureConversationToken
sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ... >
<sp:Issuer>wsa:EndpointReferenceType</sp:Issuer> |
<sp:IssuerName>xs:anyURI</sp:IssuerName>
) ?
<sp:MustNotSendCancel ... /> ?
<sp:MustNotSendAmend ... /> ?
<sp:MustNotSendRenew ... /> ?
<sp:RenewPolicy ... >
<sp:CancelPolicy ... >
<sp:AmendPolicy ... > /sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy This
optional element is a policy assertion that contains the policy indicating the
requirements for obtaining the Security Context Token. /sp:SecureConversationToken/wsp:Policy/sp:BootstrapPolicy/wsp:Policy This element
contains the security binding requirements for obtaining the Security Context
Token. It will typically contain a security binding assertion (e.g.
sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts)
describing the parts of the RST/RSTR messages that are to be protected. /sp:SecureConversationToken/wsp:Policy/sp:Renew
Policy This
optional element is a policy assertion that contains the policy indicating the
requirements for renewing the Security Context Token. /sp:SecureConversationToken/wsp:Policy/sp:RenewPolicy/wsp:Policy This
element contains the security binding requirements for renewing the Security
Context Token. It will typically contain a security binding assertion (e.g.
sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts)
describing the parts of the RST/RSTR messages that are to be protected. /sp:SecureConversationToken/wsp:Policy/sp:CancelPolicy This
optional element is a policy assertion that contains the policy indicating the
requirements for cancelling the Security Context Token. /sp:SecureConversationToken/wsp:Policy/sp:CancelPolicy/wsp:Policy This
element contains the security binding requirements for cancelling the Security
Context Token. It will typically contain a security binding assertion (e.g.
sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts)
describing the parts of the RST/RSTR messages that are to be protected. /sp:SecureConversationToken/wsp:Policy/sp:AmendPolicy This
optional element is a policy assertion that contains the policy indicating the
requirements for amending the Security Context Token. /sp:SecureConversationToken/wsp:Policy/sp:AmendPolicy/wsp:Policy This
element contains the security binding requirements for amending the Security
Context Token. It will typically contain a security binding assertion (e.g.
sp:SymmetricBinding) along with protection assertions (e.g. sp:SignedParts) describing the parts
of the RST/RSTR messages that are to be protected.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]