Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Liberty Alliance Project:Liberty ID-FF Bindings and Profiles SpecificationVersion: 1.2-errata-v2.01200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242If the service provider does not support the LECP-advertised Liberty version, the service provider MUST return to theLECP an HTTP 501 response with the reason phrase "Unsupported Liberty Version."The responses in step 3 and step 6 SHOULD NOT be cached. To this end service providers and identity providersSHOULD place both "Cache-Control: no-cache" and "Pragma: no-cache" on their responses to ensure thatthe LECP and any intervening proxies will not cache the response.3.2.4.2.3. Step 4: HTTP Request with In step 4, the LECP determines the appropriate identity provider to use and then issues an HTTP POST of the in the body of a SOAP message to the identity provider’s single sign-on service URL. Therequest MUST contain the same as was received in the from the service provider in step 3.Note:The identity provider list can be used by the LECP to create a user identifier to be presented to the Principal.For example, the LECP could compare the list of the Principal’s known identities (and the identities of theidentity provider that provides those identities) against the list provided by the service provider and then onlydisplay the intersection.If the LECP discovers a syntax error due to the service provider or cannot proceed any further for other reasons (forexample, cannot resolve identity provider, cannot reach the identity provider, etc.), the LECP MUST return to theservice provider a with a indicating the desired error element as definedin [LibertyProtSchema]. The containing the error status MUST be sent using a POST to theservice provider’s assertion consumer service URL obtained from the element of the . The POST MUST be a form that contains the field LARES withthe value being the protocol message as defined in [LibertyProtSchema], containing the. The MUST be encoded by applying a base64 transformation (refer to[RFC2045]) to the and all its elements.3.2.4.2.4. Step 6: HTTP Response with In step 6, the identity provider responds to the by issuing an HTTP 200 OK response. Theresponse MUST contain a single in the body of a SOAP message with content asdefined in [LibertyProtSchema].The identity provider MUST include the Liberty-Enabled HTTP header following the same processing rules as definedin 3.2.5.1.The Content-Type MUST be set to application/vnd.liberty-response+xml.If the identity provider discovers a syntax error due to the service provider or LECP or cannot proceed any furtherfor other reasons (for example, an unsupported Liberty version), the identity provider MUST return to the LECP a containing a with a indicating thedesired error element as defined in [LibertyProtSchema].3.2.4.2.5. Step 7: Posting the Form Containing the In step 7, the LECP issues an HTTP POST of the that was received in the SOAP response in step 6. The MUSTbe sent using a POST to the service provider’s assertion consumer service URL identified by the element within the obtainedfrom the identity provider in step 6. The POST MUST be a form that contains the field LARES with the value beingthe protocol message as defined in [LibertyProtSchema]. The MUST be encoded by applying a base64 transformation (refer to [RFC2045]) to the andLiberty Alliance Project33