Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

More documents

Recommendations

Info

Liberty Alliance Project:Liberty ID-FF Bindings and Profiles SpecificationVersion: 1.2-errata-v2.0User AgentService ProviderIdentity Provider1. GET ?RelayState=2. Obtain IdP3: 302; Location: ?()4: GET ?()6: 302; Location: ?RelayState=&SAMLart=5. ProcessAuthnRequest7: GET ?RelayState=&SAMLart=8. SOAP POST: ()9: 200 OK SOAP: ()11: 200 OK: ()10. Process Assertion761762763764765766767768769770771772Figure 2. Liberty artifact profile for single sign-onThis profile description assumes that the user agent has already authenticated at the identity provider prior to step 1.Thus, a valid session exists for the user agent at the identity provider. When implementing this profile, all processingrules defined in Section 3.2.1 for the single sign-on profiles MUST be followed. Additionally, the following rulesMUST be observed as they relate to steps 3, 6 and 7:3.2.2.1.1. Step 3: Single sign on Service with In step 3, the service provider’s intersite transfer service responds and instructs the user agent to access the singlesign-on service URL at the identity provider.This step may take place via an HTTP 302 redirect, a WML redirect deck or any other method that results in the useragent being instructed to make an HTTP GET or POST request to the identity provider’s single signon service.This response MUST adhere to the following rules:773774775776777778779780• The response MUST contain the identity provider’s single sign-on service URL (for example, as the Locationheader of an HTTP 302 redirect, the action attribute of an HTMLform or the href attribute of a elementin a WML redirect deck).• The identity provider’s single sign-on service URL MUST specify https as the URL scheme.Note:Future protocols may be adopted and enabled to work within this framework. Therefore, implementers areencouraged to not hardcode a reliance on https.• The response MUST include one of the following:Liberty Alliance Project22
Liberty Alliance Project:Liberty ID-FF Bindings and Profiles SpecificationVersion: 1.2-errata-v2.0781782783784785786787788789790791792793• A component containing the protocol message as defined in [LibertyProtSchema]with formatting as specified in Section 3.1.2.Note:The element of the message can be used by the serviceprovider to help maintain state information during the single sign-on and federation process. Forexample, the originally requested resource (i.e., RelayState in step 1) could be stored as the valuefor the element, which would then be returned to the service provider in the in step 7. The service provider could then use this information to formulate theHTTP response to the user agent in step 11.• An HTTP form containing the field LAREQ with the value of the protocol messageas defined in [LibertyProtSchema]. The MUST be encoded by applying a base64transformation (see [RFC2045].Implementation examples:794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837• HTTP 302 Redirect 302 Location: https://?• HTML Form POST• WML Redirect with POST...Contacting IdP. Please wait.........Liberty Alliance Project23
Page 1 and 2: Liberty Alliance Project:Version: 1
Page 3 and 4: Liberty Alliance Project:Liberty ID
Page 21: Liberty Alliance Project:Liberty ID

Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Create successful ePaper yourself

Delete template?

Save as template?