Identity Management? I'll Get My Coat...
Debugging Identity Connectors with Sun IDM and Netbeans
Thought it was about time I finally checked out the new open source Identity Connectors that are to replace the Resource Adapters within Sun Identity Manager. Looking at Sun IdM 8.1 Patch 5 you can see that as more Identity Connectors reach ready state they are being shipped with subsequent IdM releases. Here's a peek at what Connectors ship with 8.1 Patch 5.

Expect this list of Connectors to grow in the future. For those of you wondering if you need to manually reconfigure your system to use the new Connectors do not fear since there's a migration facility to migrate your existing Resource Adapters to become Connectors. Here's the project page that shows you what Connectors are shipped with which Sun IdM release.
An important gotcha is that the Connector bundles are not present in /WEB-INF/lib as other third party jar's , as the project page states, "IDM searches for local Identity Connector bundle files with .jar suffix in the WEB-INF/bundles directory within your web app. First, make sure that this folder is present in your IDM deployment. If it doesn't exist, create it". So make sure you're looking in WEB-INF/bundles!
My end goal here was to configure a test system for debugging, so I could learn about the code execution flow by using Netbeans (or your fav IDE) to trace the Identity Connector code. I've got Netbeans 6.5.1 installed locally and used the Versioning/SVN feature to check out the source code from identityconnectors.dev.java.net.
For my testing I want the Database Table Connector, so you can either checkout the whole head of the trunk or select the individual bundle that you're interested in. For me this involved grabbing the databasetable and dbcommon folders from SVN.

Once I had the source checked out locally I quickly unpacked Tomcat6 and deployed IDM 8.1.0.5 inside of Tomcat by copying the idm.war to /apache-tomcat/webapps folder.
Next thing is to enable the JPDA debugger - aka the Java Platform Debugger Architecture (JPDA) technology. This is pretty easy, with Tomcat I created a new script within ./bin to help me with this, here's the script:
more ./startupdebug.sh
export JPDA_ADDRESS=8000
export JPDA_TRANSPORT=dt_socket
./catalina.sh jpda start
I created a Netbeans Java Application Project and included the DatabaseTableConnector source that I had previously checked out from the Identity Connectors SVN repository as source folders. Now from within Netbeans I can attach to the Tomcat instance that is JPDA enabled on port 8000. Select "Attach Debugger" from the Debug menu of Netbeans...

On the following screen validate your port and host name....

From within Netbeans you should now be able to see the Debugger Console with the following output:
"Attaching to greasemonkey.home:8000
User program running"
Now you can set breakpoints and trace your Identity Connector 

Identity Connectors IRC Channel
Following in the footsteps of other Sun Identity Management open source IRC rooms such as #opends and #opensso you can now find a dedicated IRC room for the new open source Identity Connector technology that's previewed in Sun Identity Manager 8.1. The room is available at #identityconnectors
JOIN ##iam,#opends,#opensso, #identityconnectors
Identity Suite Tutorials Available Online for FREE
If you're looking to get an insight into the Sun Identity product stack by following some self-paced short labs there's some great online material available in Wiki format here
Great to see initiatives like this.
Sun IdM & Virtual Desktop Infrastructure Demonstrator
So I finally got around to encoding and uploading this video that shows in about 10 minutes how the Sun Identity Management suite can complement the Sun VDI product. The products used in this demon included the following (in no particular order)
Our goal (Joachim Andres and I) was to show how Sun are uniquely placed to provide the whole stack from the operating system, smartcards, SunRay thin client device, through to the desktop delivery mechanism including the actual virtualised image and to top it all off a splash of Identity Management (IdM) in the form of Single Sign On and Provisioning services.
The benefits of the Sun Virtual Desktop solution are so many it's hard to actually express it clearly I keep fumbling
I truly believe that this market is huge and one hopes that Sun and their partners can make significant progress helping our customers implement desktop virtualization. I'm not going to list all the benefits of Sun VDI and the supporting software stack above, I'll let the VDI product manager explain in person here
Remember, your desktop is not your PC or Mac, it's where you get your work done ! The desktop can be delivered independent of the actual physical device you're using, that's the whole point, use the internet to get your work done wherever you may be and whatever device you may be using.
Hope you find the demo useful, it actually includes several use-cases that I had to deliver to a Telco in the UK on a proof of concept, so these are real customer driven use-cases. Here's the demo link
Eureka!
Congratulations to those at Eurikify, enjoy your new home!
News posted yesterday concerning CA to acquire the role management vendor.
This surely reinforces the Role Compliance and Role Lifecycle Management investment taken by Oracle and Sun on their acquisitions of Enterprise Role Management products (Bridgestream and Vaau respectfully). It was surely only a matter of time before other big boys swooped on the remaining pure play vendors such as Eurikify..
Looking at the big Identity Management Suite vendors there appears only to be Novell and IBM who haven't announced some kind of enterprise role management/role compliance suite component.
Sun Secure Global Desktop and OpenSSO Integration
A close colleague of mind, Joachim Andres , myself and Andy Hall worked together on a customer project to setup web SSO integration using OpenSSO with Sun Secure Global Desktop. This work we did is a great example of the use of policy agents with existing applications and using trusted authentication mode with SGD (with Directory Services Integration configured for SGD in the background). The policy agent sets the REMOTE_USER
server variable and SGD is configured to pick that up rather than use
its own login page. With that, and a tweak to SGD's logout logic to
send the browser to OpenSSO's logout page, we have a very neat
integration. Download the document that Joachim wrote here
Latest Identity Suite
Right so moving on.. Let's take some time to remind ourselves of the compelling Identity suite that we now have. It's been some time now since the Vaau acquisition bought us their RBACx product and we can shortly expect the first Sun engineered release of Sun Role Manager with much closer integration links to Sun Identity Manager and support for mysql as the db repo. Can't wait to get my hands on those binaries and see how we can further assist customers solve their Identity and Role compliance issues.

Next generation Directory Market hots up, Sun's OpenDS 1.0 RELEASED!
OpenDS 1.0 RELEASED![Read More]
Sun Identity Manager & SGD Password Cache Integration
Last week at the Grenoble Software Technical Event based at the Grenoble Engineering Center in the French Alpes I demonstrated the integration of Sun Identity Manager and the Sun Secure Global Desktop (SGD) products. One area of interest was the SGD Password Cache integration. Why is this of interest? Well let me explain the use-case.
SGDs raison d'ĂȘtre is to securely deliver your desktop anyplace anytime to almost any devise. The applications on your desktop usually require a username & password to gain access. When you launch such an application for the first time SGD attempts to authenticate you to that application using the credentials which you specified when authenticating to SGD. If this fails then SGD will prompt you for a username/password to auth against the application, this is shown below:

You can see above there's a "Save Password" checkbox that if checked will securely persist whatever you entered within SGD itself.
If you hit the default Administrative URL for SGD of http://<servername>/sgdadmin you'll be able to see the Password Cache entries, this is shown below. On the left hand side of this table is the user identity with which you authenticated to SGD itself, folllowed by the Server name which served up the application and finally the user identity which is understood by the application itself.

So imagine the popular use-case where Sun Identity Manager is being used to process employee self-service password change. A user logs onto the system and invokes the Change User Password workflow via the webpage, they specify a new password and Identity Manager pushes this password out to the resource accounts that are linked. All of a sudden the password previously stored by SGD is out of sync with the target resource, now as a convenience we want to update the SGD Password Cache directly from within the workflow associated to the changeUserPassword IDM workflow process, how is this done?
To start with I developed a NetBeans 6 Java project and imported the relevant SGD webservice jar files which where as follows:
opt/tarantella/webserver/tomcat/5.0.28_axis1.2/common/lib
axis.jar
commons-discovery-0.2.jar
commons-logging-1.0.4.jar
jaxrpc.jar
saaj.jar
xerces.jar
/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/shared/lib
sgd-webservices.jar
Before we go any further I'd strongly recommend reading the SGD webservices section on wikis.sun.com kudos to the SGD engineering team for sharing information like this in Wiki form for all to use 
Those that know Sun Identity Manager workflow will understand how easy and simple it is to directly invoke java using XPRESS invoke command, the completed changeUserPassword workflow that calls the SGDHelper class to manage the SGD Password Cache can be downloaded here
Any questions or improvements feel free to chip in!
Password Cache? 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.
Forrester Wave
Having just spent a week locked in a snow bound room at the Sun Burlington campus I'm pleased to say that we successfully completed the Forrester Wave event. Forrester sent over an Identity Management analyst who walked through a thorough set of use-cases regarding Identity Management.
Now some of you might remember back in January 2006 Sun where voted by Forrester the leader in the User Provisioning Market with our Sun Java Systems Identity Manager product.
It was a real challenge to demonstrate all the use-cases in the one day time limit we were given, usually to walk through such a wide range of topics relating to Identity would take at least several days if not a week. Forrester where interested in seeing Identity Management use-cases relating to use compliance (certification and SOD), ease of provisioning to federation and access management (both Web SSO and Enterprise SSO). Needless to say we where all impressed by the stamina and range of knowledge with the Forrester analyst, not many people could keep up with the huge array of Identity Management experience and knowledge that Sun fielded that cold day in Boston.
Expect to see the report from Forrester in the first quarter of 2008.
Enterprise Role Management, any good?
If you follow Identity Management and have been awake recently you'll have seen the buzz around the Vaau "intent to acquire" made by Sun, if not check here. I had the privilege to work alongside Vaau on a proof of concept recently for a major UK retail financial institution. This particular prospect had requirements for Identity, Access and Role Management and had selected Sun and another vendor.
The requirements where pretty typical these days I'd guess and an increasing number of deals are mandating that RBAC be included in their product evaluation criteria:
Today's Page Hits: 100
www.flickr.com
|
| « November 2009 | ||||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 7 | 8 | |
11 | 12 | 13 | 14 | 15 | ||
17 | 18 | 19 | 20 | 22 | ||
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | ||||||
| Today | ||||||