Monday Mar 12, 2007

Lightbulb is Dead; Long Live OpenSSO Extensions!

Last October, we released the first SAML 2.0 implementation in PHP, codenamed 'Project Lightbulb' (because Lightbulb fits into LAMP) and a sub-project of OpenSSO. In the few months since then, other folks have proposed similar extensions to OpenSSO, and the 'Lightbulb' name has looked increasingly anachronistic, particularly since the core OpenSSO project has always fully supported LAMP with its Apache HTTP Server and Tomcat policy agents.

Today, we launch OpenSSO Extensions, OpenSSO's code incubator, with three initial modules:

So - what is an OpenSSO Extension? Well, it's any piece of code that either

  • extends OpenSSO to provide new functionality, for example, the OpenID identity provider, or
  • interfaces with OpenSSO, extending other systems, such as the PHP Client SDK and SAML 2.0 relying party.

If you have an idea for extending OpenSSO in an interesting way, then click here to participate!

Tuesday Feb 06, 2007

Norway using Access Manager/Federation Manager for SAML 2.0

It being RSA week, the news comes thick and fast... I've just seen the press release announcing that the Government of Norway has deployed a whole slew of Sun hardware and software, including Access Manager and Federation Manager, for its pioneering citizen portal, MinSide (English translation: MyPage). Quoting from the press release:

[...] the MinSide [MyPage] portal will roll-out six initiatives that will enable secure, browser-based access to healthcare, tax, motor vehicle registration, social security, student loans and many other government services.


As part of the solution, Sun Java(TM) System Access Manager and Sun Java(TM) Federation Manager help the Norwegian government manage secure access to services by offering single sign-on (SSO) as well as enabling federation across trusted networks of government agencies, service providers and customers. It provides open, standards-based authentication and policy-based authorization with a single, unified framework. This improved security framework is based on the Liberty and SAML standards to protect all aspects of the portal.

The Liberty Alliance website has a presentation by Dag Efjestad that gives much more detail. Cool stuff, Norway - douze points!

Switch on SAML for PHP with Project Lightbulb

Marina Sum and I just published an article over on the Sun Developer Network (SDN) - Switch on SAML for PHP with Project Lightbulb. The article walks through some of the Project Lightbulb code, following the single sign-on process. If you want to work with the Lightbulb code, or you just want a better idea of how SAML 2.0 works, this article is for you.

As I mention in the conclusion, we'll look at SAML 2.0 single logout and the circle-of-trust in a future article.

Friday Feb 02, 2007

SSOCircle Goes Live

Hu Liu, a regular on the OpenSSO IRC channel (#opensso on freenode), has just launched SSOCircle - a SAML 2.0 identity provider (IdP), based on the Open Federation code (part of the OpenSSO project). Quoting from the home page, SSOCircle's mission is:

  • Identity Provider for everyone
  • JumpStart SingleSignOn/Federation deployments
  • Leverage federation for Web 2.0 apps
  • Providing ready-to-use solutions
  • SAML 2.0 standard based testing platform
  • Exchange of information/experience
  • Building the SSOCircle of Trust

I just registered, logged in and tried out SAML 2.0 SSO with the sample service provider site (based on Sampo Kellomäki of Symlabs' ZXID) and it all works nicely. At last there is an easy to use, public site to play with SAML 2.0.

As soon as I get a chance I'm going to add SSOCircle as the default IdP in Lightbulb and write a how-to for getting your first service provider up and running.

Thanks, Hu, and best of luck!

Tuesday Dec 05, 2006

YADIS/XRI Identifier Resolution with SAML 2.0

This week at Internet Identity Workshop 2006b I've been demonstrating some work I've been doing to combine YADIS/XRI Identifier Resolution (as in OpenID) with SAML 2.0 Web Browser SSO Profile. The user experience is:

  1. I go to a service provider (relying party)
  2. I enter my identifier (URL or i-name)
  3. I authenticate at my identity provider
  4. I can access services at the service provider

The magic takes place between steps 2 and 3: the service provider resolves the user's identifier, which might be a URL or an i-name, to the location of a SAML 2.0 identity provider. The service provider can now do vanilla SAML 2.0 with the identity provider. The easiest way to see what's going on is via a demo, so, here you go:

Click to view Flash presentation

By the way - the service provider is implemented on top of Project Lightbulb. I need to do some tidying first, but I'll put the YADIS/XRI code there soon.

UPDATE - coverage of this demo at IIW2006b:

Sunday Dec 03, 2006

links for 2006-12-03

  • This normative document defines terms used throughout the OASIS Security Assertion Markup Language (SAML) specifications and related documents.

Friday Dec 01, 2006

57 Varieties of Identifier-based Authentication

Johannes posts about the ongoing work on exploring the synergies between SAML and OpenID in an entry titled Eve and Pat, SAML and OpenID. It's worth reading to get an idea of just how things are coming together. One correction, though, Johannes - you give a table of identifier-based authentication flavours, but you left an important one out. Here is a fuller version:

Of course, the magic of Yadis makes this all very transparent to the user, but, I wonder, how do IdPs and SPs decide which flavour they prefer?

Thursday Nov 30, 2006

SAML 2.0 meets Web 2.0 at

Nice article covering yesterday's Liberty Alliance webcast from Rich Seeley over at All the URLs for that webcast and this week's closely related podcast are here.

It's great to see momentum building in this whole area - Liberty, SAML, OpenID, OpenSSO... As I say in the podcast, this is a tremendously exciting time to be involved in digital identity.

Thursday Nov 02, 2006

Added Single Logout to Lightbulb - SAML 2.0 in PHP

I just finished adding single logout to the 'Lightbulb' OpenSSO SAML 2.0 PHP implementation. I'll take this opportunity to reiterate: THIS IS BY NO MEANS PRODUCTION CODE. There are probably bugs, there are certainly shortcuts. This is development out in the open.

Please do feel free to pick this up, play with it, suggest improvements - even contribute code. As I mentioned before, there is a bit of process to this, but I think it's more than worth it.

The next step for me now is to write a how-to on getting an IdP up to play with...

Friday Oct 20, 2006

Q&A on the OpenSSO SAML 2.0 PHP work

Yesterday I announced the first drop of my SAML 2.0 PHP code. I've had a few questions since then - here they are, with answers:

  • Q: Can I contribute to this?
    A: Of course! This was the whole point of releasing this code as open source. I know a little about SAML 2.0, but I'm no PHP expert. I'd welcome PHP folks to take a look and suggest/make improvements. See the OpenSSO governance for more information on contributing.
  • Q: Is this 'pure' PHP?
    A: That depends on your definition of 'pure'. No custom modules are required. It does use openssl, mysql, dom and xml, but support for these is pretty standard. The default PHP5 in my Ubuntu 6.06 had everything I needed.

Please do leave comments with any further questions - I'll update this entry with the answers.

Thursday Oct 19, 2006

Switching on the Lightbulb

Over the past few months I've had a side project - implementing a SAML 2.0 service provider (SP) in PHP. I originally set out using PHP/Java Bridge and got something working (I even presented it [pdf] at Identity Open Space in Vancouver), but I was inspired by Kim Cameron's success in implementing InfoCard in PHP to try a more direct approach.

Rob Richard's XML Security implementation provided the impetus I needed to get a 'pure' PHP SAML 2.0 SP working. Rob kindly allowed me to adopt the XML Security code into OpenSSO (note that the base XML security code is still, and will continue to be, available, in its original public domain form, at Rob's page) and I set forth hacking away.

Well - I'm done with an initial version. SAML 2.0 POST profile works. There is no artifact profile, no single log out, no bells or whistles. It does verify the assertion signature (via PHP's integration with openssl) and checks that the certificate fingerprint matches what it expects from that identity provider.

There is some general documentation on SAML-enabling PHP [odt], and some specific documentation on this code [odt]. I'll write a step-by-step guide to getting it up and running next...

UPDATE - some FAQs here.

Monday Oct 16, 2006

Federation - Italian Style

Somehow, this passed me by back in March/April, but a presentation at Sun's Customer Engineering Conference last month brought it back into focus - Italy's Ministry of Transportation has deployed a new Motorist Portal, providing services such as online payment of vehicle registration fees and traffic tickets.

What's interesting here is that drivers log in to the Motorist Portal to view their driving record, vehicle registration etc, but make payments via another government agency, Poste Italiane. The Motorist Portal acts as a SAML identity provider, with Sun Java System Access Manager authenticating users and providing single sign-on to Poste Italiene's service provider for 40 million Italian drivers - possibly one of the biggest live SAML deployments in the world.

You can find out more in this short SunTV presentation and the Italian press release (English translation via Google).

Wednesday May 24, 2006

Anatomy of a SAML-Secured SOAP Message

As promised, here is a dissection of the SOAP message from yesterday's post on the AM 7.1 Beta Secure Web Services Tutorial.

First, let's take another look at the secured message in its entirety:

<env:Envelope xmlns:env="" xmlns:enc="" xmlns:ns0="" xmlns:wsu="" xmlns:xsd="" xmlns:xsi="">
    <wsse:Security xmlns:wsse="">
      <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="s69f7e258e30da2b9b9f5799d4eb0c548782432bf" IssueInstant="2006-05-24T05:52:32Z" Issuer="patlinux" MajorVersion="1" MinorVersion="1">
        <saml:AuthenticationStatement AuthenticationInstant="2006-05-24T05:52:30Z" AuthenticationMethod="urn:com:sun:identity:Application">
              <KeyInfo xmlns="">
                <KeyName>CN=patlinux, OU=Sun Java System Application Server, O=Sun Microsystems, L=Santa Clara, ST=California, C=US</KeyName>
        <Signature xmlns="">
            <CanonicalizationMethod Algorithm=""/>
            <SignatureMethod Algorithm=""/>
            <Reference URI="#s69f7e258e30da2b9b9f5799d4eb0c548782432bf">
                <Transform Algorithm=""/>
                <Transform Algorithm=""/>
              <DigestMethod Algorithm=""/>
      <Signature xmlns="">
          <CanonicalizationMethod Algorithm=""/>
          <SignatureMethod Algorithm=""/>
          <Reference URI="#se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">
              <Transform Algorithm=""/>
            <DigestMethod Algorithm=""/>
          <SecurityTokenReference xmlns="" wsu:Id="STR1">
            <KeyIdentifier ValueType="" wsu:Id="sbee70b80d8b330875655b8956d13ff5a4199ca1d">s69f7e258e30da2b9b9f5799d4eb0c548782432bf</KeyIdentifier>
  <env:Body wsu:Id="se0ffabd98ecfdf194adc0c8ac8fb4edabf65cd3a">

It's pretty hard to see the wood from the trees here, particularly since there are two signatures in there. Here is a somewhat abstracted version:

Working from the inside out:

  • The SAML AuthenticationStatement contains data from a SAML authority concerning a subject - that is, the person/service/device/whatever whose identity is in question here. In the AuthenticationStatement we can see a Subject element containing a NameIdentifier (which we could use to refer to this subject in future exchanges with this SAML authority) and a SubjectConfirmation element. The ConfirmationMethod element tells us how the assertion is bound to the subject. In this case, it is Holder of Key, indicating that the SubjectConfirmation also carries a public key. Assuming we trust the SAML authority, we can be confident that anything we receive that is signed with the corresponding private key came from the subject. You can clearly see an RSA public key, with its modulus and exponent, in the KeyInfo element.
  • Moving down, immediately after the AuthenticationStatement is a Signature (white in the diagram). This is an enveloped signature over the parent Assertion. This signature binds the Assertion to the issuing SAML authority. It contains an X.509 certificate which we can use to verify the signature and decide if the assertion has come from a trusted SAML authority.
  • So, now we have an assertion that contains the public key of some subject known to a SAML authority. The next Signature element (blue in the diagram) is a detached signature of the SOAP Body. This signature binds the Body (and its payload - the actual stock request that the recipient is going to process) to the subject. This Signature does not contain an X.509 certificate. Instead, it has a KeyInfo element that references the earlier Assertion - the recipient is to use the public key in the Assertion to verify the signature.

The recipient thus has all the pieces it needs to verify that

  • The message was not tampered with in transit
  • The body was signed by some subject identified by a SAML authority identified by an X.509 certificate.

In this entry I've covered the stock request as it appears on the wire. Next time round I'll look at how Access Manager 7.1's JSR 196 provider makes all this happen in the web container (App Server) with no code in the required in your web service consumer or producer.


Friday Dec 09, 2005

ADFS, WS-Federation and SAML in the enterprise

James McGovern left an interesting comment on my previous entry concerning WS-Federation and SAML 2.0.

James says

A customers perspective is slightly different than what you suggest in your posting. MS is doing the right things with WS-Federation. After all, if you consider that 99.9% of all Fortune enterprises and their B2B partners have AD installed, they would eliminate not only the need for SAML but for enterprises to buy yet another piece of software that really should be bundled with the OS in order to solve for problems across enterprises. Federated identity conversation is somewhat consumer focused. Would be great if participants could put on an enterprise lens when considering solutions....

Thanks for the comment, James. I think you're right, up to a point. Microsoft is doing the right things, from the perspective of MS themselves and 'MS shops'. If you have a pure MS infrastructure, then WS-Federation and ADFS are great news. If you have a mixed environment, and some or all of your business partners have a mixed environment, then this is good news, but it could have been so much better. After all, if MS had issues with the way SAML worked in their environment, they could have contributed to the SAML 2.0 process in OASIS and we would have had the 'grand convergence' of federation specs. But, for their own reasons, they chose not to engage there.

I spent Monday with one of our biggest enterprise customers. They have selected SAML 2.0 for web single sign-on across their various departments and divisions and with external partners. WS-Federation makes no sense for them as they have no MS SSO infrastructure - it's all Sun, IBM and Oracle (Oblix). In common with the 99.9% of Fortune enterprises you mention, they do have AD as a NOS directory, so ADFS support for WS-Federation rather than SAML just complicates their lives.

Leaving aside the question of whether federation technology should be bundled with the OS, the fact is that Microsoft are only now beginning to fill the gaps in federation. They have chosen to do so using proprietary specifications (remember, WS-Federation is a specification, not a standard) rather than an existing open standard with wide adoption. It will be an interesting couple of years as enterprises make their choices. But again, choosing products using a common standard would have been so much better than having to bet on a spec.

Thursday Dec 08, 2005

Update on WS-Federation, SAML 2.0

I posted my previous blog entry as feedback to Patrick Harding's SAML 2.0 article in Network World. Patrick was kind enough to reply this morning, saying that Network World TechUpdate articles focus on a single technology which, in this case, was SAML 2.0 rather than the wider topic of Federated Web SSO. Never mind that writing about the convergence of federation technology into SAML 2.0 without mentioning WS-Fed is like not mentioning the elephant in the room.
Anyway, Patrick gave me his permission to post his excised paragraph:
What about WS-Federation? Anyone using Microsoft's upcoming Active Directory Federation Service will be using WS-Federation, as it is the protocol supported by ADFS. WS-Federation will likely become the second important federation protocol going forward, even though the primary focus of the WS-\* initiative is web services. While one could argue the industry would be better off with a single standard, having two is a whole lot better than having seven.
I can't agree more - taking the pragmatic view, we now have a converged standard for federated web single sign-on supported by the entire industry save a single vendor. Perhaps Microsoft could one day join us at OASIS in bringing the benefits of WS-Federation to SAML



« August 2016