The answer about my previous questions:

------------------------------------------------------

Edson,

I believe your question is, how does a service tell a client the required 
content for the SAML token the client will present to the service. The 
sp:RequestSecurityTokenTemplate can include a wst:Claims elements whose content 
can be used to specify claims that are required by the service the client wants 
to talk to.

Hope this helps,

Gudge

--------------------------------------------------------------------
Edson


Srinath Perera escreveu:
Hi Edson;

The questions and the thoughts here are interesting. I have some doubts
about the original question, but using a WS-Trust cenario.

yes, When I asked the original question I was more lean toward
SAMLToken, but I have been reading ..( and thanks to Ruchith) now I
think best way to handle this is considering trust!!

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?


+1 , exactly .. in my case it is a authorization satement ..but in
generel it could be either. I guss again we have start reading specs!!
to find a way. I will check does trust say somthing

Thanks
Srinath

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]




--
============================
Srinath Perera:
   http://www.cs.indiana.edu/~hperera/
   http://www.bloglines.com/blog/hemapani

---------------------------------------------------------------------
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]

Reply via email to