Hi all,
The questions and the thoughts here are interesting. I have some doubts
about the original question, but using a WS-Trust cenario.
Let's assume the scenery where a relying part defined in your WSDL needs
a SAML Token issued by a STS (WS-Trust). So, I think that the policy
into WSDL should be thus:
Syntax:
<wsp:Policy>
<sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient";>
<sp:Issuer>
<EndpointReference
xmlns="http://schemas.xmlsoap.org/ws/2004/08/addressing";>
<Address>http://AdressOfTheSTS.com</Address>
</sp:Issuer>
<sp:RequestSecurityTokenTemplate>
<!-- Policy defined by the Service for the STS -->
<wst:TokenType>urn:oasis:names:tc:SAML:1.1</wst:TokenType>
<wst:KeyType>
http://schemas.xmlsoap.org/ws/2004/04/trust/SharedKey </wst:KeyType>
</sp:RequestSecurityTokenTemplate>
</sp:IssuedToken>
</wsp:Policy>
The SAML token could include an autentication statement , autorization
statement or attribute statement. Let's suppose that the service need a
autorization stantemente or client atribute issued by the STS into SAML
token .So, the question is: how to express this policy for the STS?
Edson
Prateek Mishra escreveu:
srinath,
Here are some thoughts:
My impression of the IssuedToken assertion is as follows: it is used
by a relying party to inform a client about a WS-Trust authority whence
it should acquire an assertion. So it is quite a complicated beast and
I dont see exactly how it fits in your scenario.
Your SAML assertion is a bearer assertion; so the simplest model is
that it is placed in the SOAP header by the requestor and sent to the
recipient. So here is how you would specify that:
(1) Use of SAMLtoken assertion -
<sp:SAMLToken>
<wsp:Policy>
<sp:WSSSAMLV20Token11> !--- or whatever the version is
</sp:SAMLToken>
Note that there is no way to indicate the SubectConfirmationMethod of
the token required.
(2) Is the SOAP message being sent over HTTPS? One of the simplest
use-cases for SAML is a bearer assertion sent over server-side HTTPS. You
would then combine the SAMLtokenAssertion with the transport binding.
So putting it all together we have:
<wsp:Policy>
<sp:SupportingToken>
<wsp:policy>
<sp:SAMLToken>
<wsp:Policy>
<sp:WSSSAMLV20Token11> !--- or whatever the version is
<wsp:Policy>
</sp:SAMLToken>
<s/p:SupportingToken>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken />
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
</wsp:Policy>
</sp:TransportBinding>
<wsp:Policy>
- prateek
I am trying to specify that the client need a SMAL assertion included
in the request by specifying it using WS-Policy. The Assertion is a
token issued by third part which act as a capability token.
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
<Conditions NotBefore="2006-02-03T17:39:57.240Z"
NotOnOrAfter="2006-02-03T18:09:57.240Z">
<AudienceRestrictionCondition> ...
</AudienceRestrictionCondition>
</Conditions>
<AuthorizationDecisionStatement
Resource="http://www.extreme.indiana.edu/lead/TestCMD_Simple_Fri_Feb_03_12_39_52_EST_2006_653199";
Decision="Permit">
<Subject>
<NameIdentifier>/C=US/O=Indiana
University/OU=Computer Science/CN=Hemapani Srinath
Perera</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:bearer</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
<Action
Namespace="http://www.extreme.indiana.edu/lead";>Run</Action>
</AuthorizationDecisionStatement>
<ds:Signature> .... </ds:Signature>
</Assertion>
I find two options to do that so far,
1) IssuedToken Assertion, as by the 6.3.2 IssuedToken Assertion of
WS-Secuirty Policy Specification
2) SMAL Assertion, as by 6.3.8 SamlToken Assertion of WS-Secuirty
Policy Specification
If anyone has use either of the method, please give me a pointer
1) can anybody recommend using one over the other? Or a better way to
do it
2) Can do anyone have a example of using either kind of Policy
assertion?
Thanks
Srinath
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
