OpenSSO: Cross Domain Single Sign On

Transcription

1 OpenSSO: Cross Domain Single Sign On Version 0.1 History of versions Version Date Author(s) Changes /30/2006 Dennis Seah Contents Initial Draft. 1 Introduction 1 2 Single Domain Single Sign-On 2 3 Cross Domain Single Sign-On 2 4 Installation and Configuration Server Installation and Configuration J2EE Agents Installation and Configuration Web Agents Installation and Configuration Introduction The Cross Domain Single Sign-On (CDSSO) is a feature that allows OpenSSO solution to protect web resources in different DNS domains. CDSSO makes it possible for users to authenticate once against OpenSSO server in a primary DNS domain, and then access protected resources in different DNS domains. CDSSO is an OpenSSO s proprietary mechanism. it is designed before Security Assertion Markup Language (SAML) and the Liberty Alliance Project existed. It is relatively easier to set up and manage CDSSO than SAML and Liberty in certain cases. 1

2 2 Single Domain Single Sign-On This is section, we describe how the OpenSSO solution works in Single DNS Domain setup. Browser Agents Server access protected resource redirect to login page present login page authenticate session information is added to HTTP Cookie redirect to original URL get the session info from Cookie grant/deny according to policy decision response Send policy decision request compute policy decision send Policy Decision Response Figure 1: Single Domain Single Sign-On From figure 1, it is evident that the Agents is able to retrieve the Session Information from the HTTP Cookie because Server and Agents are on the same domain. When we have Agents and Server on different DNS Domains, Agents can no longer retrieve the Session Information from the Cookie. This paper describes one solution to this issue. 3 Cross Domain Single Sign-On From figure 2, the same piece of session information is stored in two Cookies, one under Server DNS Domain and the other under Agents DNS Domain. The 2

3 agents is able to retrieve it and validate it against the server accordingly. 4 Installation and Configuration 4.1 Server Installation and Configuration 2. Follow the instruction in opensso/products/federation/openfm/readme to get the external libraries and build the binaries; 3. deploy openfm.war and configure it (visit the URL of deployed application to access configuration page) 4.2 J2EE Agents Installation and Configuration 2. Follow the instruction in opensso/products/j2eeagents/readme to get the external libraries and build the binaries; 3. install the agents for the web server; 4. edit AMAgents.properties to set CDSSO related parameters. com.sun.identity.agents.config.cdsso.enable = true com.sun.identity.agents.config.cdsso.redirect.uri = /agentapp/sunwcdssoredirecturi com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = com.sun.identity.agents.config.cdsso.clock.skew = 0 com.sun.identity.agents.config.cdsso.trusted.id.provider[0] = 4.3 Web Agents Installation and Configuration 2. Follow the instruction in opensso/products/webagents/readme to get the external libraries and build the binaries; 3. install the agents for the web server; 4. edit AMAgents.properties to set CDSSO related parameters. 3

4 com.sun.identity.agents.config.cdsso.enable = true com.sun.identity.agents.config.cdsso.cdcservlet.url = 4

5 Server Browser Agents CDCServlet Auth Policy access protected resource redirect tocdcservlet User has not authenticated Forward request to Login Page present login page authenticate session information is added to HTTP Cookie (in the server s DNS Domain) redirect request back to CDCServlet send AuthNResponse to Agent via HTTP Redirect Extract Session Information from AuthNResponse and add it to HTTP Cookie (in the agent s DNS Domain) redirect to original URL get the session info from Cookie Send policy decision request compute policy decision grant/deny access according to policy decision response send Policy Decision Response Figure 2: Cross Domain Single Sign-On 5