Identity Management? I'll Get My Coat...
Sun Grenoble Engineering Identity/Desktop Event
This coming week at the Grenoble Engineering Center I'll be presenting on the subject of Identity Management within the scope of desktop virtualisation, in particular integration with the Sun Secure Global Desktop product. The agenda can be found here
The background to this was a proof of concept that I performed with Simon Ross and Graham Hares both Sun UK employees at a major communications customer within the UK.
The technology integration was actually really quite straightforward, as a side thought, isn't this always the case, if it involves custom coding and buckets of glue it's likely it ain't gonna fly let alone scale.
We used the new version 4.4 of Secure Global Desktop (SGD) along with the Java Enterprise 5 release for Access Manager and Identity Manager. Without detailing every single configuration step the high level picture goes like this. We wanted to be able to achieve the following:
We achieved the first object using the Sun Access Manager Policy Agent 2.2 for Apache webserver 1.3, since SGD 4.4 uses Apache Webserver as the front end http listener. Install the policy agent in the usual manner making sure that this value is set within the AMAgent.properties file:
com.sun.am.policy.agents.config.profile.attribute.fetch.mode=HTTP_HEADER
This setting ensures that the userId of the authenticated session is passed through to Apache and then ultimately through to the Tomcat server that actually runs the majority of SGD. In order to complete the SSO through to SGD one needs to configure SGD for third party authentication. The SSO works since SGD inspects the servlet environment variable of REMOTE_USER and if present creates a user session.
The key step here (doco) in order to get it working is to modify the Tomcat server.xml to look like the following, this ensures that Apache forwards the value of REMOTE_USER to the Tomcat engine:
<!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -->
<Connector port="8009" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="0"
useURIValidationHack="false" tomcatAuthentication="false"
protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>
The great thing is that SGD can be configured to run it's authentication and application policy engine from an external source, such as an LDAP server. This is termed, Directory Services Integration within SGD land and can be read about here the ideal companion here is the Sun LDAP Directory Server.
Using the Sun Access Manager Realm ResourceAdapter from within Sun Identity Manager we provisioned users directly into Access Manager giving them the ability to SSO into SGD. Using Identity Manager workflow self service workflows enabled users to request access to Access Manager LDAP Groups which drive the application visibility from their SGD webtop.
So the Sun Directory Server is the backbone here, providing the persistent storage for users and groups. This LDAP server provides the SSO repository as well as for the means for application access from SGD (if a user is within this particular LDAP group then they get access to this application from SGD).
So yes this was brief and not a detailed write up but what it proves is that it is possible and fairly straight forward to protect Secure Global Desktop using the Sun Java System Access Manager and provide Single Sign On services. This brings about a ton of advantages let alone the possibility of using one of the many authentication schemes provided by Access Manager out of the box.
Posted at 01:02PM Jan 14, 2008 by Paul Walker in Sun | Comments[1]
Today's Page Hits: 52
| « May 2008 | ||||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 | |
| Today | ||||||
www.flickr.com
|
This is the reason why I like SSGD :
With this configuration no administration (besides configuring new applications) is needed since administration is done via the Directory Server and you get all the tools for delegated administration, password management, account creation/deletion from the tools provided for the Directory Server (which could also be an Active Directory).
I am looking forward to your presentation and like to see if I can learn new things (we are running this solution our self and have (are going) to implementing this setup at customers :) )
See you tomorrow!
Posted by Remold Krol on January 14, 2008 at 07:32 PM CET #