RE: [ws-sx] RE: Issue 162: no way to specify the policies for renew and cancel

["Will Hopkins" <whopkins@bea.com>]

Hi Marc,

 

We agree that it's possible to attach policy to STS WSDL in the fashion you describe.  We also agree that, in general, it's better to use existing mechanisms rather than invent new ones.

 

That said, we still believe there's an argument for adding renew and cancel semantics to the bootstrap mechanism:

• The existing standard provides for bootstrap policy even though the same "attach policy to STS WSDL" argument could be made for the issue semantic as well -- if issue is OK, why not renew and cancel?

• Having renew and cancel policy available from service's WSDL is very convenient for the WS-SC case.

• WSDL for STS service is pretty minimally specified, and there is no normative text or WSDL file that expresses issue, renew, cancel, or validate as distinct operations.

• For the case that service and STS are co-located, dependence on STS WSDL implies that the hosting service's WSDL must include WSDL for the STS itself, along with appropriate policy attached at the proper points.  While legal, this construction is a bit odd, and must be accounted for by implementations in any number of different contexts.  (Think about, e.g., tools that generate web service code starting from a WSDL file.)

 

I suspect that many, if not most, implementations have punted on generating/consuming strict WSDL for STS services co-located with WS-SC services, and interoperate today only by virtue of bootstrap policy and various guesses (often faulty) about policy for renew and cancel.  The ability to express renew and cancel policy as <boostrap> will provide for a high degree of interop at a minimum cost to implementors.  The alternative -- reliance on policy attached to WSDL -- is likely to be a high barrier to compliance (and thus interop) for many vendors.

 

Regards,

 

Will

 

---

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Friday, March 07, 2008 1:01 PM
To: Marc Goodner; Corinna Witt; ws-sx@lists.oasis-open.org
Subject: [ws-sx] 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]
Sent: Wednesday, February 06, 2008 9:54 AM
To: Corinna Witt; ws-sx@lists.oasis-open.org
Subject: [ws-sx] Issue 162: no way to specify the policies for renew and cancel

 

Issue 162

 

From: Corinna Witt [mailto:cwitt@bea.com]
Sent: Tuesday, February 05, 2008 8:48 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: NEW Issue: no way to specify the policies for renew and cancel

 

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>

  ) ?
  <wst:Claims Dialect="..."> ... </wst:Claims> ?
  <wsp:Policy xmlns:wsp="...">
    (
      <sp:RequireDerivedKeys ... /> |
      <sp:RequireImpliedDerivedKeys ... /> |
      <sp:RequireExplicitDerivedKeys ... />
    ) ?
    <sp:RequireExternalUriReference ... /> ?
    <sp:SC13SecurityContextToken ... /> ?

    <sp:MustNotSendCancel ... /> ?

    <sp:MustNotSendAmend ... /> ?

    <sp:MustNotSendRenew ... /> ?
    <sp:BootstrapPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:BootstrapPolicy> ?

    <sp:RenewPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp: RenewPolicy> ?

    <sp:CancelPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:CancelPolicy> ?

   <sp:AmendPolicy ... >
      <wsp:Policy> ... </wsp:Policy>
    </sp:AmendPolicy> ?
  </wsp:Policy>
  ...
</sp:SecureConversationToken>

 

/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.

 

Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.