Tuesday Jul 10, 2007

SSO from OpenSSO to ADFS via WS-Federation

Not too many blog entries lately, as I've been elbow-deep in code - Friday saw the first ever single sign-on from OpenSSO to Microsoft Active Directory Federation Services (ADFS) via WS-Federation (click on the screenshot for a closer look at the output of the ADFS test app). This is OpenSSO acting as an account partner (in ADFS terminology), or identity provider, to ADFS as a resource partner, or service provider. There is a lot of work still to do - single logout, account and attribute mapping, etc, but the core SSO protocol support is all there now.

Friday Jun 22, 2007

Initial WS-Federation support committed to OpenSSO

The WS-Federation service provider and configuration CLI code was committed into OpenSSO yesterday - this PDF gives some basic instructions on getting started with WS-Fed and OpenSSO. Note that this is just the initial drop of code - still to come is identity provider support.

Give it a whirl and send us feedback at dev(at)opensso.dev.java.net.

Monday Mar 05, 2007

Development in the Open II - OpenSSO WS-Federation SDD Posted

Well, I've been beavering away on the design for WS-Federation support in OpenSSO [PDF]. I just uploaded it to the OpenSSO project site and sent it to the dev@opensso mailing list. It's a first draft, so there are places that need some more detail and clarity, but I think it's ready for a first review. If you do have any feedback, then please sign up to the OpenSSO project and submit your comments via the dev mailing list.

Wednesday Jan 10, 2007

Development in the Open - OpenSSO WS-Federation SRS Posted

I just pulled the trigger on the first draft OpenSSO WS-Federation Software Requirements Specification (SRS) - see it on the dev-AT-opensso.dev.java.net mailing list here. This is the first requirements document to be completed under the new OpenSSO development process. I have to admit, it feels pretty strange having this out there in the open!

As I mention in the email, comments are welcome, so, please, sign up to the OpenSSO project and submit your feedback via the dev mailing list.

Wednesday Dec 20, 2006

Now that WS-Federation 1.1 is out...

[WS-Federation 1.1], when are thought leaders at vendors like Sun going to come clean and mention this in their blogs. Their silence is suspicious! This is clearly going to become the industry standard for federated single sign-on, despite anything those bozos at OASIS say.

gratuitous irrelevant picture

With credit and apologies to James McGovern for stealing his format Smile!

Tuesday Jun 20, 2006

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.

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 2.next?
About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
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
    
       
Today