[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Tech Overview outstanding issues
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]