del.icio.us’ link posting function seems to be on the blink right now; here are my last few, lovingly hand-pasted…
The title of this blog entry is a direct quote from an email we received from a very happy Sun SE today. He’s kindly given me permission to share it. I added the links for convenience
Date: May 23, 2008 7:04:20 AM PDT
Subject: Federation POC Success
Wanted to let you know I just had worked on a POC for a long term oppty for some common activities going on at several government operations.
I used build 4 of OpenSSO and the most exiting part for me and please share with the team was:
1) How nice the install experience was
2) The Federation Wizards are awesome (only suggestion is to allow user to name the MetaAlias; I don’t think you can add more than two entities using the wizard)
3) Integration with third party (HP Select Federate) was a dream!!!
1) Install AM
2) Run Local IDP Wizard
3) Run Remote SP Wizard to point to HP Data URL
4) HP Points to my URL for Meta Data
5) Test and WORKED FIRST TIME!!!
No kidding!! I have no idea of effort for the HP install, but with that in place, my entire time spent before I was exchanging SAML assertions with HP was about an hour (had I known I would be breaking personal records here, I think I could have sped that up)
Best news is a partner who recommends Sun witnessed that (jaws dropped).
Thanks to you and your team for what is definitely the best version of AM ever!!!
Says it all, really. Kudos to the entire AM engineering team, and, indeed, the wider OpenSSO community for what is turning into something very very special.
The CommunityOne folks have posted all the 2008 slides online – you can find them via the session catalog (don’t forget the username/password for downloading the PDFs – contentbuilder/doc789) or just get the OpenSSO slides directly.
The inimitable Paul Madsen writes on the Fedlet today, wondering
Would the fedlet, once deployed by an SP, be reusable with other IDPs (than the one that created it initially) and thereby be considered a quick and easy way to SAML enable an SP? I bet not.
On the contrary, my dear Madsen, it could indeed be reused with other IdPs. The Fedlet is configured via SAML 2.0 metadata, saved to a directory on disk. The very first time you visit the Fedlet’s deployment URI, it offers to save configuration to disk:
At this point, as explained on the screen, you can expand the Fedlet WAR manually and copy the files yourself, or let the Fedlet do it for you. In either case, you can edit the SAML 2.0 metadata to use any SAML 2.0 identity provider (or providers). OpenSSO even includes an ‘unconfigured’ Fedlet for doing this all completely manually.
So, yes, the Fedlet is a quick and easy way to SAML enable an SP!
UPDATE (5/22/08) – Paul. Says. It. Was. All. Down. To. Misplaced. Punctuation.
It’s Friday afternoon, time for some fun! We’ve put together a neat little game where you can protect your enterprise from the like of disgruntled former employees, Sarbox gremlins and the deadly auditors with the help of Sun’s identity management products: Identity Hero! Here’s a screenshot:
Go save your enterprise!
Marina is covering JavaOne 2008 for the Sun Developer Network – she’s written a review of our Monday OpenSSO session, which also appears in the today’s ‘JavaOne Today’ newspaper. Lucas Jellema at AMIS Technology also wrote a nice review, even including a screenshot of OpenSSO.
If you’re at JavaOne, come along to the Sun stand in the pavilion – we’re on pod 181, just under the poster of an old geezer with a red pickup. I’ll be here today (Wednesday) and tomorrow (Thursday) from 11am to 2pm, but feel free to stop by any time the pavilion is open for a demo and a chat.
If you’re following OpenSSO at all, you can’t have failed to notice the recent buzz around the Fedlet – from Daniel (complete with screencast), Eve Mark D, Mark H, Tatsuo, Derrick, Marina and Daniel at Sun to Coté at RedMonk and Enrico at Tenthline.
Briefly, the ‘Fedlet’ is a package that a SAML 2.0 identity provider can create to quickly federation-enable a small service provider. The idea is that, if you’re running a single web application, you’re not going to want to deploy a whole ‘nother server to run a standalone service provider. What you want is a little package of code and configuration to federation-enable your web app. You want the Fedlet.
I’ve been wrapped up in demos and travel for the past month or so, so I haven’t had much of a chance to play with the Fedlet. Since I’m planning to demo it in my session at CommunityOne on Monday, I thought I’d better do so – I set aside this afternoon to get it working. Turns out I was a little pessimistic there – here’s what I did, in less than an hour:
- Update from OpenSSO CVS (
cvs -q update -dP
- Cleaned out previous build detritus and built the WAR file (
ant clean && ant server-war
- Deployed onto Glassfish (don't forget to change GF's
-client JVM option to
-server, as detailed in the release notes!)
- Pointed Flock (my preferred web browser du jour) at the newly deployed OpenSSO at http://demo.example.com:8000/opensso (I alias demo.example.com to 127.0.0.1 in /etc/hosts), configured OpenSSO to use the embedded OpenDS instance for its configuration and user stores.
- Logged in as amadmin, created a SAML 2.0 identity provider and a Fedlet.
- Unzipped the Fedlet, deployed it into Glassfish.
- Ran the Federation validator to check that SSO is operational.
When you spend your time in the weeds of a project, you always half expect any given step to fail due to some issue or another. Perhaps some recent fix destabilized something; perhaps some errant process has eaten my laptop's memory; whatever. So it was extremely gratifying when all of the above passed off without a hitch. I won't tell you what I muttered under my breath as the federation validator completed and gave me the thumbs up, but the second word was "cool!"