|
By Jim Faut, with contributions from Rick Palkovic, March 2009
|
|
|
[Part 1] [Part 2] [Part 3] [Part 4] [Part 5]
In this example, you explore an OpenSSO deployment designed for simple single sign-on and policy protection.
Using the Live HTTP Headers and HackBar add-ons for the popular Mozilla Firefox web browser, you can gain insight into OpenSSO interactions and better understand how the system works. For an overview, software configuration details, and links to other examples, see Troubleshooting OpenSSO with Firefox Add-Ons: Part 1, Introduction
Contents
In this example, the application host has a protected URL at http://agent.customer.com. A specific policy allows access to this URL for all authenticated users. To test this policy, navigate to http://agent.customer.com and capture the URL redirects that occur for the protected site.
The following sequence diagram depicts the interaction that occurs among the user's browser, the policy agent, and OpenSSO.
Figure 1: Simple Single Sign-On Sequence Diagram |
In your browser, navigate to the protected URL http://agent.customer.com. The browser is redirected to the OpenSSO login page, and the corresponding HTTP traffic is captured in the Live HTTP Headers window. For the OpenSSO server and policy agent host configured as
described in Part 1, the following data will be captured:
1. User Makes Initial Request
The initial request starts the Single Sign-On (SSO) process. This request is triggered when a user navigates to a URL that is protected — in this case, http://agent.customer.com. This URL is protected by an OpenSSO policy agent. A specific policy allows access only to authenticated users.
|
http://agent.customer.com/
GET / HTTP/1.1
Host: agent.customer.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
|
2. Agent Sends Redirect
The following data shows the redirection taking place. Note that the redirect URL, shown in bold, includes a goto parameter that contains the location of the original page request. The goto parameter specifies what page to display to the user after successful authentication.
|
HTTP/1.x 302 Moved Temporarily
Server: Sun-Java-System-Web-Server/7.0
Date: Wed, 25 Feb 2009 00:31:24 GMT
Location: http://osso.customer.com:8080/opensso/UI/Login?goto=http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
Content-Length: 0
----------------------------------------------------------
|
3. Browser Follows Redirect
The browser follows the redirect and requests the OpenSSO login page. Note that the goto parameter is retained as part of the URL.
|
http://osso.customer.com:8080/opensso/UI/Login?goto=http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
GET /opensso/UI/Login?goto=http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
HTTP/1.1
Host: osso.customer.com:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
|
4. OpenSSO Renders Login Page and Sets Cookies
OpenSSO inspects the URL parameters that were in the request and then renders a login page. OpenSSO also sets some cookies that are used for proper processing of OpenSSO requests. For example, the amlbcookie can be used by a load balancer to provide server stickiness in a multiple-host deployment.
|
HTTP/1.x 200 OK
X-Powered-By: JSP/2.1
Server: Sun Java System Application Server 9.1_02
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: Enterprise 8.0 Build 6(2008-October-31 09:07)
AM_CLIENT_TYPE: genericHTML
Set-Cookie: AMAuthCookie=AQIC5wM2LY4SfcyswVyDTU85Pjqpb+6Ny2a/GK4FK/9bync=@AAJTSQACMDE=#;
Domain=.customer.com; Path=/
Set-Cookie: amlbcookie=01; Domain=.customer.com; Path=/
Set-Cookie: JSESSIONID=ad7d0974591160f883115e69312e; Path=/opensso
Content-Type: text/html;charset=UTF-8
Transfer-Encoding: chunked
Date: Wed, 25 Feb 2009 00:31:24 GMT
----------------------------------------------------------
|
In the next sequence, the user enters a login name and password. These credentials are submitted to OpenSSO and the user is issued a cookie representing the SSO Token. The user is then redirected back to http://agent.customer.com.
5. User Submits AuthN Credentials
The user enters a login name and password and clicks the Login button.
|
http://osso.customer.com:8080/opensso/UI/Login?AMAuthCookie=AQIC5wM2LY4SfczJVsBLMgyTHNyx9dwVkijvg0iPob%2BgSwM%3D%40AAJTSQACMDE%3D%23
POST /opensso/UI/Login?AMAuthCookie=AQIC5wM2LY4SfczJVsBLMgyTHNyx9dwVkijvg0iPob%2BgSwM%3D%40AAJTSQACMDE%3D%23 HTTP/1.1
Host: osso.customer.com:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://osso.customer.com:8080/opensso/UI/Login?goto=http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
Cookie: JSESSIONID=ddb368d66cceb0a7613e6eca668d; AMAuthCookie=AQIC5wM2LY4SfczJVsBLMgyTHNyx9dwVkijvg0iPob+gSwM=@AAJTSQACMDE=#; amlbcookie=01
Content-Type: application/x-www-form-urlencoded
Content-Length: 149
IDToken0=&IDToken1=testuser&IDToken2=password&IDButton=Log+In&goto=aHR0cDovL2FnZW50LmN1c3RvbWVyLmNvbTo4MC9pbmRleC5odG1s&encoded=true&gx_charset=UTF-8
|
Note that the goto parameter is also submitted as part of the authentication request. However, the value of the parameter has changed. The original goto parameter was much more recognizable as a URL, as shown below:
Original goto parameter: http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
New goto parameter: aHR0cDovL2FnZW50LmN1c3RvbWVyLmNvbTo4MC9pbmRleC5odG1s
The goto parameter has been encoded. You can use the HackBar add-on to decode the parameter and verify that it still represents the same location.
To decode the goto parameter:
a.) Reveal the HackBar pane in the Firefox browser by choosing Tools > Show/hide hackbar from the browser menu bar.
Figure 2: Displaying the HackBar Add-On |
b.) Copy the goto parameter from the Headers tab of the Live HTTP Headers window as shown in Figure 3.
Figure 3. Copying the goto Parameter From Live HTTP Headers |
c.) Paste the value into the HackBar pane. Then click the Split URL glyph on the left. The result is shown in Figure 4.
Figure 4: Splitting the URL of the goto Parameter |
d.) In the HackBar pane, select the value of the goto parameter and choose Encoding > Base64 Decode.
Figure 5: Decoding the goto Parameter |
e.) You can now read the plain text value of the parameter, as shown in Figure 6. Note that it still represents the original page that was requested.
Figure 6: Reading the goto Parameter |
6. OpenSSO Sets SSO Token and Redirects to Agent
In the next sequence, the OpenSSO server responds by redirecting the browser back to the original page. OpenSSO also sets the iPlanetDirectoryPro cookie, which represents the SSO Token. This cookie is set with Domain=.customer.com so that it can be passed to the target server.
|
HTTP/1.x 302 Moved Temporarily
X-Powered-By: Servlet/2.5
Server: Sun Java System Application Server 9.1_02
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: Enterprise 8.0 Build 6(2008-October-31 09:07)
AM_CLIENT_TYPE: genericHTML
X-AuthErrorCode: 0
Set-Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfczJVsBLMgyTHNyx9dwVkijvg0iPob+gSwM=@AAJTSQACMDE=#; Domain=.customer.com; Path=/
Set-Cookie: AMAuthCookie=LOGOUT; Domain=.customer.com; Expires=Thu, 01-Jan-1970 00:00:10 GMT;
Path=/
Location: http://agent.customer.com:80/index.html
Content-Type: text/html; charset=iso-8859-1
Content-Length: 0
Date: Wed, 25 Feb 2009 14:37:08 GMT
----------------------------------------------------------
|
7. Browser Follows Redirect and Passes SSO Token
The browser now follows the redirect instruction and passes the SSO Token as part of the request. Note that the browser passes the SSO Token because the target server is in the same domain as the cookie domain.
|
http://agent.customer.com/index.html
GET /index.html HTTP/1.1
Host: agent.customer.com:80
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6) Gecko/2009011912 Firefox/3.0.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://osso.customer.com:8080/opensso/UI/Login?goto=http%3A%2F%2Fagent.customer.com%3A80%2Findex.html
Cookie: amlbcookie=01; iPlanetDirectoryPro=AQIC5wM2LY4SfczJVsBLMgyTHNyx9dwVkijvg0iPob+gSwM=@AAJTSQACMDE=#
|
8. Web Server Renders Page
Next, the policy agent validates the SSO Token. The requested page is rendered after the policy agent determines that the token is valid and that the user is authorized to see the page.
|
HTTP/1.x 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Wed, 25 Feb 2009 14:37:08 GMT
Content-Type: text/html
Last-Modified: Mon, 16 Feb 2009 13:28:23 GMT
Content-Length: 12038
Etag: "2f06-499969f7"
Accept-Ranges: bytes
----------------------------------------------------------
|
Firefox, combined with the Live HTTP Headers and HackBar Add-ons, is a powerful troubleshooting tool. Inspecting the traffic flowing through a browser can provide valuable insight into the transactions that comprise an OpenSSO solution. These tools are even more valuable in an environment that has the OpenSSO and policy agent applications protected with SSL encryption. In this case, it is impossible to "snoop" the traffic on the network. These tools expose the data in its unencrypted form so that this type of troubleshooting is possible.
More examples will be added as they become available:
Do you have comments about this article? We welcome your participation in our community. Please keep your comments civil and on point. You may optionally provide your email address to be notified of replies - your information is not used for any other purpose. By submitting a comment, you agree to these Terms of Use.
|
 Jim Faut, a Technical Manager in Sun Federal's Professional Services group, specializes in OpenSSO, GlassFish, Identity Manager, and Portal deployments. He has been deploying solutions with Java technology since 1999. Jim's blog focuses on Sun software products and related technologies. |
 Rick Palkovic is a staff writer for Sun Developer Network. He has written about the Solaris OS and Java technologies for longer than he likes to admit, composing everything from man pages to technical white papers.
|
|
Print-friendly Version
