RE: [security-services] Tech Overview outstanding issues

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Ummm... just after the Issuer element of the samlp:Response, the example
says:
    <!-- a POSTed response MUST be signed -->

When using the POST binding with the SSO profile, it isn't the
samlp:Response that must be signed.  Per Profiles section 4.1.4.5, it is
the enclosed saml:Assertion that must be signed.

I haven't checked details of the messages yet, but I did catch that one.

Rob Philpott
Senior Technologist
RSA, The Security Division of EMC
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
Email: rphilpott@rsa.com


> -----Original Message-----
> From: Tom Scavo [mailto:trscavo@gmail.com]
> Sent: Friday, October 06, 2006 12:04 PM
> To: Eve L. Maler
> Cc: security-services@lists.oasis-open.org
> Subject: Re: [security-services] Tech Overview outstanding issues
> 
> On 9/29/06, Eve L. Maler <Eve.Maler@sun.com> wrote:
> >
> > Tom, thanks for offering a detailed code example!  I think an
> > SP-initiated SSO flow would be most common and most welcome.  I
> > might also reprise it somewhat in the introductory material, unless
> > people think that having two examples for similar stuff that differ
> > only in unimportant details is useful.
> 
> Attached is an SSO flow with hand-crafted example code.  Comments are
> welcome.
> 
> Tom Scavo
> NCSA/University of Illinois
> 
> ------------------------------------------------------
> SAML V2.0 Web Browser SSO Profile
> 
> This is a possible deployment of the SAML V2.0 Web Browser SSO Profile
> where the service provider (SP) and the identity provider (IdP) use
> the HTTP Redirect and HTTP POST bindings, respectively.  The message
> flow begins with a request for a secured resource at the SP.
> 
> 1) Request the target resource at the SP
> 
> The client requests a target resource at the service provider:
> 
>   https://sp.org/myresource
> 
> The service provider performs a security check on behalf of the target
> resource.  If a valid security context at the service provider already
> exists, skip steps 2--7.
> 
> 2) Redirect to the Single Sign-on (SSO) Service at the IdP
> 
> The service provider redirects the client to the Single Sign-on (SSO)
> Service at the identity provider.  A RelayState parameter and a
> SAMLRequest parameter are appended to the redirect URL.  The value of
> the SAMLRequest parameter is a URL-encoded string constructed from the
> following request:
> 
>   <samlp:AuthnRequest
>     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>     xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>     ID="identifier_1"
>     Version="2.0"
>     IssueInstant="2004-12-05T09:21:59Z"
>     AssertionConsumerServiceIndex="1">
>     <saml:Issuer>https://sp.org/SAML2</saml:Issuer>
>     <samlp:NameIDPolicy
>       AllowCreate="true"
>       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
>   </samlp:AuthnRequest>
> 
> Before the <samlp:AuthnRequest> element is URL-encoded and appended to
> the redirect URL, it is first deflated and base64-encoded (in that
> order).
> 
> 3) Request the SSO Service at the IdP
> 
> The client requests the SSO service at the identity provider:
> 
>
https://idp.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
> 
> where token is an opaque reference to state information maintained at
> the service provider and request is the encoded <samlp:AuthnRequest>
> element from step 2.  The SSO service processes the AuthnRequest (by
> URL-decoding, base64-decoding and inflating, in that order) and
> performs a security check.  If the user does not have a valid security
> context, the identity provider identifies the user (details omitted).
> 
> 4) Respond with an HTML form
> 
> The SSO service validates the request and responds with a document
> containing an HTML form:
> 
>   <form method="post" action="https://sp.org/SAML2/SSO/POST"; ...>
>     <input type="hidden" name="SAMLResponse" value="response" />
>     <input type="hidden" name="RelayState" value="token" />
>     ...
>     <input type="submit" value="Submit" />
>   </form>
> 
> The value of the RelayState parameter has been preserved from step 3.
> The value of the SAMLResponse parameter is the base64 encoding of the
> following <samlp:Response> element:
> 
>   <samlp:Response
>     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>     xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
>     ID="identifier_2"
>     InResponseTo="identifier_1"
>     Version="2.0"
>     IssueInstant="2004-12-05T09:22:05Z"
>     Destination="https://sp.org/SAML2/SSO/POST";>
>     <saml:Issuer>https://idp.org/SAML2</saml:Issuer>
>     <!-- a POSTed response MUST be signed -->
>     <ds:Signature
>       xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
>     <samlp:Status>
>       <samlp:StatusCode
>         Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
>     </samlp:Status>
>     <saml:Assertion
>       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>       ID="identifier_3"
>       Version="2.0"
>       IssueInstant="2004-12-05T09:22:05Z">
>       <saml:Issuer>https://idp.org/SAML2</saml:Issuer>
>       <!-- a Subject element is required -->
>       <saml:Subject>
>         <saml:NameID
>
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
>           3f7b3dcf-1674-4ecd-92c8-1544f346baf8
>         </saml:NameID>
>         <saml:SubjectConfirmation
>           Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>           <saml:SubjectConfirmationData
>             InResponseTo="identifier_1"
>             Recipient="https://sp.org/SAML2/SSO/POST";
>             NotOnOrAfter="2004-12-05T09:27:05Z"/>
>         </saml:SubjectConfirmation>
>       </saml:Subject>
>       <saml:Conditions
>         NotBefore="2004-12-05T09:17:05Z"
>         NotOnOrAfter="2004-12-05T09:27:05Z">
>         <saml:AudienceRestriction>
>           <saml:Audience>https://sp.org/SAML2</saml:Audience>
>         </saml:AudienceRestriction>
>       </saml:Conditions>
>       <saml:AuthnStatement
>         AuthnInstant="2004-12-05T09:22:00Z"
>         SessionIndex="identifier_3">
>         <saml:AuthnContext>
>           <saml:AuthnContextClassRef>
> 
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
>          </saml:AuthnContextClassRef>
>         </saml:AuthnContext>
>       </saml:AuthnStatement>
>     </saml:Assertion>
>   </samlp:Response>
> 
> 5) Request the Assertion Consumer Service at the SP
> 
> The client issues a POST request to the assertion consumer service at
> the service provider.
> 
> 6) Redirect to the target resource
> 
> The assertion consumer service processes the response, creates a
> security context at the service provider and redirects the client to
> the target resource.
> 
> 7) Request the target resource at the SP again
> 
> The client requests the target resource at the service provider
(again):
> 
>   https://sp.org/myresource
> 
> 8) Respond with requested resource
> 
> Since a security context exists, the service provider returns the
> resource to the client.