13.07.2015 Views

Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

Liberty ID-FF Bindings and Profiles Specification - Liberty Alliance

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Liberty</strong> <strong>Alliance</strong> Project:<strong>Liberty</strong> <strong>ID</strong>-<strong>FF</strong> <strong>Bindings</strong> <strong>and</strong> <strong>Profiles</strong> <strong>Specification</strong>Version: 1.2-errata-v2.01990199119921993199419951996The cookie MAY be either session or persistent. This choice may be made within an identity federation network, butshould apply uniformly to all providers in the network (see [<strong>Liberty</strong>ImplGuide]) for more details on cookies).3.6.2. Setting the Common Domain CookieAfter the identity provider authenticates a Principal, it MAY set the common domain cookie. The means by whichthe identity provider sets the cookie are implementation-specific so long as the cookie is successfully set with theparameters given above. One possible implementation strategy follows <strong>and</strong> should be considered non-normative. Theidentity provider may:199719981999200020012002• Have previously established a DNS <strong>and</strong> IP alias for itself in the common domain• Redirect the user agent to itself using the DNS alias using a URL specifying "https" as the URL scheme. Thestructure of the URL is private to the implementation <strong>and</strong> may include session information needed to identify theuser-agent.• Set the cookie on the redirected user agent using the parameters specified above.• Redirect the user agent back to itself, or, if appropriate, to the service provider.20032004200520062007200820092010201120123.6.3. Obtaining the Common Domain CookieWhen a service provider needs to discover which identity providers the Principal uses, it invokes a protocol exchangedesigned to present the common domain cookie to the service provider after it is read by an HTTP server in thecommon domain.If the HTTP server in the common domain is operated by the service provider, the service provider MAY redirect theuser agent to an identity provider’s intersite transfer service for an optimized single sign-on process.The specific means by which the service provider reads the cookie are implementation-specific so long as it is able tocause the user agent to present cookies that have been set with the parameters given in Section 3.6.1. One possibleimplementation strategy is described as follows <strong>and</strong> should be considered non-normative. Additionally, it may besub-optimal for some applications.201320142015201620172018• Have previously established a DNS <strong>and</strong> IP alias for itself in the common domain• Redirect the user agent to itself using the DNS alias using a URL specifying "https" as the URL scheme. Thestructure of the URL is private to the implementation <strong>and</strong> may include session information needed to identify theuser-agent.• Set the cookie on the redirected user agent using the parameters specified above• Redirect the user agent back to itself, or, if appropriate, to the service provider.<strong>Liberty</strong> <strong>Alliance</strong> Project58

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!