|
How to setup a Single Sign On server Pool DAF 5.0 supports a single sign feature which allow a client logged on one server to surf to another server with no need to re-log in on the destination server. This type of feature is difficult to implement because the HTTP protocol does not provide any mechanism designed for this purpose. DAF handles single sign on using user session transfers from server to server. This solutions has advantages but also important limitations. Advantages
Limitations
User Session transfers When a client log on a server, it creates a user session identified by a unique Ticket ID which contain also the source server address. Therefore, to initiate a user session transfer from one server to another, you simply need to forward the appropriate Ticket ID (referecing this user session on the source server) to the destination server. Upon receiving this Ticket ID, the destination server will contact the source server and import the user session. Once exported, the user session is removed from the source server. Ticket ID transfers In practice, the tricky part is to transmit the Ticket ID from the source server to the destination. One way or another, this task must be executed by the browser. The exact transmission method depend on how the Ticket ID is stored in first place by the browser ([Filter]/[User ID & Session] settings.) If all servers members of the pool belong to the same domain (svr1.domain.com, svr2.domain.com...) it is convenient to use domain cookies. This way all server will receive the Ticket ID automatically and no specific code must be added to your web pages. If all servers of the pool do not belong to the same domain, or if DAF is configured to store the Ticket ID emdebbed in the Url, some specific code must be added to each page which might forward the client to another server. The aim is to include the Ticket ID in the Url. It can be emdebbed in the path, or added as a query string parameter. 1. Define inter server communication keys If not already done, define inter servers communication keys 2. Use Ticket ID and allow session Import/Export
3. If needed, customize your pages to support the Ticket ID transmission For the single sign on to work the browser must transmit the Ticket ID when the client surf to another server. If all your servers belong to the same domain and are configured to use domain cookies, the Ticket ID will follow automatically and no specific code is required. Otherwise, you must add some code to your web pages to insert the Ticket ID in all links definition pointing another server. The Ticket ID may be emdebbed in the Url Path or added as a parameter to the query string. When a client is logged the current Ticket ID is stored as server variable "HTTP_DAFTICKETID". a. Ticket ID embedded in the Url Path With this solution, the destination server will receive the Ticket ID emdebbed in the Url. Therefore, the option to search for the Ticket ID in the url must be enabled:
The sample code below will display a link pointing to "destination.com" with the Ticket ID inserted in the Url. <% TicketID = request.servervariables("HTTP_DAFTICKETID")%>
This code should display a link similar to: - if not encrypted: http://destination.com/TID-3A618C8A6C3100000@dbiis70730622@0400A8C02637/ - if encrypted: http://destination.com/TID-6Eq6yaMRIkhVRnfskrn5G5sGkODFl440B-mF5H3gGFOhKKKbcba7qsdc5AU/ b. Ticket ID added as query string parameter With this solution, the destination server will receive the Ticket ID as a query string parameter. Therefore, the option to search for the Ticket ID in the query string must be enabled:
The sample code below will display a link pointing to "destination.com" with the Ticket ID added as a query string parameter. <% TicketID = request.servervariables("HTTP_DAFTICKETID")%> This code should display a link similar to: - if not encrypted: http://destination.com?TID=3A618C8A6C3100000@dbiis70730622@0400A8C02637 - if encrypted: http://destination.com?TID=6Eq6yaMRIkhVRnfskrn5G5sGkODFl440B-mF5H3gGFOhKKKbcba7qsdc5AU
|