Fresh out of college? Coding hero? Looking for a challenge?

Access Manager is hiring!

Are you a recent graduate? Know some Java? Interested in working in identity management – one of the most dynamic sectors of the software industry? Ready to show your coding skills to the world in an open source project?

Sun’s Identity Management engineering group has a vacancy for an entry-level coder. Click here, and tell ’em Pat sent you.

We’re looking for more experienced code wranglers, too!

A Catalyst with a difference this year…

If you haven’t been to Burton Catalyst before, this is the setup: during the day, you have the conference sessions, but no vendor expo. In the evenings, the various vendors lay on food, drink and demos in a variety of themed suites at the conference hotel. Sun’s theme this year was ‘Identity City’, complete with superheroes and a game than involved donning velcro boots and racing an opponent on a velcro floor. (Great work, as always, Bianca!) You get to wander round, sampling the victuals, watching vendor demonstrations and chatting with other attendees.

This year, unfortunately, I didn’t manage to get a full conference pass for Catalyst (there are some trade-offs inherent in the move from marketing to engineering). I did, however, get a free pass for the evening hospitality suites. These passes are pretty easy to come by – basically, just talk nicely to anyone involved in Catalyst, a hospitality suite vendor whatever. In fact, I’m guessing that, if you just showed up at the registration desk and asked nicely for a hospitality suite pass, they’d give you one.

Anyway – the upside is that I got to meet a bunch of ‘old friends’ (well, ‘old’ in Internet time) and some new folks too. I was photographed by my colleague Mark Dixon, videoed by Kaliya ‘Identity Woman’ Hamlin and, after the suites closed down, hit the town with a whole bunch of current and ex-Sun people.

The moral of the story? Even if you can’t manage to be there for the whole conference, the hospitality suites are free and great fun. Here’s looking forward to ’07!

Liberty and WS-Federation

James McGovern directed this question to me in a recent blog entry:

Pat Patterson, what would it take for you to get Liberty Alliance to embrace the WS-Federation specification? Having federation capabilities built directly into an operating system is liberating…

I’m not sure what James means, exactly, by ’embrace’, but here is an answer to a more precise question – could you mix-and-match WS-Federation with the Liberty Alliance Project‘s Identity Web Services Framework (ID-WSF)?

Well, Liberty got out of the SSO business some time ago, contributing ID-FF to OASIS for inclusion in SAML 2.0. Liberty’s technical focus is now on Web services, strong authentication and such.

ID-WSF is independent of the actual SSO mechanism – the dependency is on the token, or, more precisely, the token carrying specific information. ID-WSF 1.1 can use SAML 1.1 tokens, ID-WSF 2.0 will be able to use both SAML 2.0 and SAML 1.1 tokens.

WS-Federation’s USP is that it abstracts the token away from the SSO mechanism – a WS-Federation SSO can carry any token you like – SAML 1.1, SAML 2.0, Kerberos, whatever.

So, you can bootstrap from WS-Federation to ID-WSF if you obtain a suitable SAML token via WS-Fed SSO. Section 4 of the draft ID-WSF 2.0 Discovery Service specification defines SAML 2.0 and SAML 1.x Attributes that carry the Discovery Service endpoint reference (EPR). For example, here is a SAML 2.0 <AttributeStatement> containing a Discovery Service EPR:

<AttributeStatement
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Attribute Name="urn:liberty:disco:2005-11:DiscoveryEPR" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<AttributeValue>
<wsa:EndpointReference>
<wsa:Address>https://example.com/disco/</wsa:Address>
<wsa:Metadata>
<Abstract>
The Principal’s Discovery Service Resource
</Abstract>
<ServiceType>urn:liberty:disco:2005-11</ServiceType>
<ProviderID>http://example.com/</ProviderID>
<SecurityContext>
<SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID>
<sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" />
</SecurityContext>
</wsa:Metadata>
</wsa:EndpointReference>
</AttributeValue>
</Attribute>
</AttributeStatement>

There are some minor syntactic differences in the SAML 1.x version:

<AttributeStatement
xmlns="urn:oasis:names:tc:SAML:1.0:assertion">
<Subject>
<NameIdentifier Format="urn:liberty:iff:nameid:federated">
d0CQF8elJTDLmzE0
</NameIdentifier>
</Subject>
<Attribute AttributeName="DiscoveryEPR" AttributeNamespace="urn:liberty:disco:2005-11">
<AttributeValue>
<wsa:EndpointReference>
<wsa:Address>https://example.com/disco/</wsa:Address>
<wsa:Metadata>
<Abstract>
The Principal’s Discovery Service Resource
</Abstract>
<ServiceType>urn:liberty:disco:2005-11</ServiceType>
<ProviderID>http://example.com/</ProviderID>
<SecurityContext>
<SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID>
<sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" />
</SecurityContext>
</wsa:Metadata>
</wsa:EndpointReference>
</AttributeValue>
</Attribute>
</AttributeStatement>

Such an attribute gives you everything you need to invoke the Discovery Service on behalf of a principal – its location (https://example.com/disco/ in the examples above) and a token representing the principal – and it can be carried via WS-Federation just as easily as SAML.

It’s up to vendors to make this work. If ADFS can be customized/extended to provide the above SAML attribute in a WS-Federation SSO then other vendors’ products can consume it. No further specification or standardization is required, since, again, WS-Federation allows any token as its payload and ID-WSF doesn’t care about the SSO mechanism as long as the token carries the Discovery Service EPR.

Which brings us round to the original question – “what would it take for you to get Liberty Alliance to embrace the WS-Federation specification”. I believe this is moot, since, as I have shown, SSO is orthogonal to Liberty’s current activities. SAML 2.0, WS-Federation, come one, come all.

Finally, yes, I agree – “having federation capabilities built directly into an operating system is liberating” – it would have been even more liberating had Microsoft adopted the federation standard agreed long ago by the rest of the industry and built SAML 2.0 into the operating system. However, we live in the real world and work to satisfy our customers’ requirements. You will see WS-Federation support in future versions of our products – in fact, we’ve already done a PoC showing WS-Federation.

Solaris 10 /etc/hosts gotcha

Often, when I’m setting up a test system or a demo, I’ll use bogus fully qualified domain names (FQDNs), adding entries to /etc/hosts (which is nowadays a symbolic link to /etc/inet/hosts). Today, I was setting up federation; my identity provider (IdP) is at amdemo.example.com and my service provider (SP) is at fmdemo.partner.com. I set up the IdP, appending amdemo.example.com to the line in /etc/hosts that said 192.168.1.31 amdemo and all was well – I could browse to amdemo.example.com and see Access Manager.

On to the SP. I do the same thing, appending fmdemo.partner.com to the line in /etc/hosts that contains fmdemo, browsing to fmdemo.partner.com and… I get some site on the internet. Hmmm. Check /etc/nsswitch.conf – it tells me that it will check files (i.e. /etc/hosts) before DNS. Hmmm. If I comment out the nameserver from /etc/resolv.conf, I can browse to fmdemo.partner.com and see Federation Manager. Strange.

After much man page reading, the answer is… /etc/inet/ipnodes. It turns out that, even if you don’t choose IPv6 support, Solaris 10 will read /etc/inet/ipnodes before /etc/hosts and, if there is no ipnodes value, then go to DNS. So, the answer is to copy the relevant line from /etc/hosts to /etc/inet/ipnodes. I do that and, hey presto, I can see Federation Manager at fmdemo.partner.com!

The key here is the comment in /etc/nsswitch.conf that says

# Note that IPv4 addresses are searched in all of the ipnodes databases
# before searching the hosts databases.

So, with these lines in /etc/nsswitch.conf:

hosts:      files dns
ipnodes:    files dns

The search order is: /etc/inet/ipnodes, DNS, /etc/inet/hosts then DNS again.

This has actually bitten me before. I’m blogging it this time to increase my chances of actually remembering it.