Friday Feb 27, 2009

XACML and SAML - a Match Made in... 2005

Over at NetworkWorld's Security: Identity Management Alert, Dave Kearns weighs in on the ongoing federated provisioning debate with Federated provisioning could exist. While Dave is right to highlight the promise of the Liberty Alliance's Identity Governance Framework (IGF), he is way off the mark regarding XACML and SAML. Dave writes:

Some have suggested that XACML (eXtensible Access Control Markup Language) might be the answer. But it [...] suffers from the same problem as SPML (no interaction with SAML) [...]

This is patently not true! Four years ago, OASIS defined the interaction between XACML and SAML in SAML 2.0 profile of XACML v2.0 [PDF], part of the XACML 2.0 specification set. Since then, SAML/XACML has been implemented in a range of products, including Sun OpenSSO Enterprise, with interoperability between seven vendors' products demonstrated at the OASIS XACML Interop Demo (held at the RSA Conference, April 2008).

XACML and SAML, best buddies since February 2005

Monday Jan 12, 2009

Did You Know That Federated Identity Deployments Are More Secure Than You Think?

James McGovern asks the rhetorical question "Did you know that many federated identity deployments are insecure?". I'll leave James' criticisms of OpenID and Cardspace to the respective experts, as I'm really only on the periphery of those communities, but let's have a look at the insecurities he perceives in SAML-based federation...

James' main point on federation is:

Many of the products will perform a lookup of the subject within a SAML assertion against an LDAP store [...] So, if salesforce.com is a SP and supports multiple customers of which Credit Suisse is one and the other is say Goldman Sachs. Salesforce.com would have a trust relationship with both of them but what would prevent a rogue Goldman Sachs employee from putting into their directory the subject (say email address) of a Credit Suisse employee and allowing it to be passed along?

There are multiple layers of protection against this kind of attack. The most obvious mitigation is the use of SAML 2.0 persistent identifiers. A persistent identifier is an opaque string (in practice, a long random sequence of characters, such as ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M that is shared by exactly one identity provider and one service provider to identify a given user. Now, let's assume that our rogue Goldman Sachs employee manages to discover the persistent identifier of a Credit Suisse employee (difficult, since this value would only be shared between Salesforce.com and Credit Suisse). On receiving a SAML assertion from Goldman Sachs, Salesforce.com would look the user up with (Goldman Sachs, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), which would not match (Credit Suisse, ZG0OZ3JWP9yduIQ1zFJbVVGHlQ9M), so the assertion would be rejected. You can check out the OpenSSO source code to see how this works - persistent IDs are scoped to the (identity provider, service provider) pair, so you MUST use the identity provider when resolving them, since there is no guarantee that two identity providers won't accidentally (or otherwise!) generate the same ID.

Can our rogue Goldman Sachs employee hack around with the assertion, to try to fool Salesforce.com and get access to the Credit Suisse data? Well... he can try... Even forging every field in the assertion, without the Credit Suisse signing key, he cannot impersonate a Credit Suisse employee, since, ultimately, the signing certificate will not match that on file for Credit Suisse. Of course, it's possible for an implementation bug to subvert all this careful specification work, as we saw with the Google/SAML vulnerability discovered last year.

Now, anyone familiar with Salesforce.com's implementation will be quick to point out that they don't in fact use SAML 2.0 persistent ID's, instead giving you the option of 'Federation ID' or Salesforce username. The former is an arbitrary string that the admin can set in the user entry at Salesforce.com, so you could use this in the same way as a SAML 2.0 persistent ID. Let's focus on the latter - Salesforce username, which is often, in fact, the user's email address - James' use case!

Now, let's imagine our rogue Goldman hacker has set his email address to someone@creditsuisse.com. Well, the remainder of the assertion has Goldman Sachs all over it, so, assuming Salesforce.com are using the assertion issuer name when they look up the email address, our hacker is still denied entry. And remember, we can't forge the issuer name, since that will provoke a mismatch on the certificate. I clearly can't see inside Salesforce.com's SAML implementation to check that they do match on the assertion issuer, but I can tell you that OpenSSO does exactly this. Again, SAML provides the framework to federate safely, but it's down to you, the implementer, to get it right. And you can improve your chances of doing so by using an off-the-shelf implementation rather than rolling your own.

James' other point on federation:

[...] federation products tend to be separate and distinct from web access management products. So, in this scenario the application wouldn't even have an opportunity to protect itself as the federation product would simply create a cookie and not pass context as to how this user was authenticated.

Speaking for OpenSSO, we do not separate federation and web access management. You can assign an authentication level to SAML federation and use that in policy. Perhaps 'level 1' is SAML, 'level 2' is local username/password and 'level 3' is a hardware token; the 'order entry' app might specify level 2, while the 'payroll' app would specify that level 3 authentication is required. There are other ways of implementing this that spring to mind; segregating local and federated users into different domains for example, or testing some attribute in the user profile.

All good points from James, I have to say, illustrating the fact that, even if your wire protocol is secure, implementation issues can easily lead to vulnerabilities.

Tuesday Nov 25, 2008

Slides and Blog Reaction from Tokyo Liberty Alliance Day 2008

Here are the slides [PDF] from my presentation at the Tokyo Liberty Alliance Day last month. The picture on the right is of the Microsoft speaker, Shigeya Tanabe, talking about Microsoft's recent commitment to SAML 2.0, which he illustrated by a screen cap from my blog entry on the subject.

There was some blog coverage too, (all in Japanese):

I'll be taking tomorrow off to extend the Thanksgiving break a little, so you'll probably not hear from me until next week. To all those in the USA - Happy Thanksgiving!

Tuesday Oct 28, 2008

Welcome, Microsoft, to the World of SAML 2.0

This is a blog entry I've been wanting to write for a LONG time... At the Professional Developers Conference today, Microsoft announced that 'Geneva', their forthcoming identity platform (part of which is the successor to Active Directory Federation Services), will not only support SAML 2.0 as a token format, but also as a single sign-on protocol. The Federation Wars are over!!!

Lots more to read on the subject:

Me, I'm looking forward to testing OpenSSO with Geneva. We live in interesting times indeed

Tuesday Jul 08, 2008

SAML and Windows Login

Interesting post from James on the possibilities of Windows desktop systems being SAML identity providers (IdPs). Currently, a similar mechanism exists for desktop single sign-on from Windows (via SPNEGO, using Kerberos tokens, which, by the way, OpenSSO and Access Manager support directly, no IIS 'bounce' required), but this is limited to a single enterprise's AD infrastructure and can be pretty tricky to deploy. It's easy to imagine IE submitting SAML assertions to service providers at Internet scale in the way James describes. Microsoft seem to be reconsidering the case for supporting SAML 2.0, so they may even be receptive to something like this.

Where James does get things twisted (to use one of his favorite expressions ) is in imagining that Sun and Oracle have much influence on our friends in Redmond. Microsoft's paying customers have MUCH more clout than their competitors/partners. I'd suggest, James, that you band together with your peers at enterprises such as GM and Boeing, who I know, from their participation in Concordia, have very similar desires. Heck, you could even roll up your sleeves and dive right in to Concordia - it's free, very enterprisey and Microsoft participate with open ears...

Monday Mar 03, 2008

Burton Group Tech Watch podcast: Adoption and State of the Federation Market

Gerry Gebel of The Burton Group kindly invited me to participate in their most recent podcast, on the topic 'Adoption and State of the Federation Market', along with Patrick Harding of Ping Identity and David Miller of Covisint. Do Patrick and I come to (verbal) blows? Listen in and find out! [MP3]

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.

Tuesday Jun 19, 2007

Single Logout with SAML 2.0 and PHP

Back in February, Marina Sum and I co-wrote an article on the OpenSSO SAML 2.0 PHP Extension, or Lightbulb, as it was then known. The sequel to that article - Single Logout: A Demo just went live at Sun Developer Network: Marina and I provide an update on Project Lightbulb's evolution into an OpenSSO Extension as well as a look at circles of trust and single logout in SAML 2.0. As before, we look at a simple example message flow, then delve down into the PHP code to see how it all works. Click here for the article.

Thursday Jun 14, 2007

Slides on Feide, SAML 2.0, OpenID and more

Andreas over at Feide has just published a bunch of presentations he, um, presented the other day in Oslo. Great stuff - and I really like the sparse, clean look. I HATE slides with 15 bullets in 10 point text. The presentations cover the basics of SSO, SAML 2.0, OpenID and a look at Nordic/European collaboration in the education sector. Check them out.

Friday May 11, 2007

Silos, Schmilos!

Ben Laurie posts flame-bait this morning, with an entry titled 'Liberty Loves Silos'. I always find it amazing how folks ascribe the most sinister motivations to Liberty - maybe now that a load of our (previously private) mailing lists are publicly visible, people will see that we are really fluffy and cuddly (except Conor, of course, he's a bit prickly).

Anyway - back to the point... My understanding (I wasn't there for a lot of the early work, so I'm happy to be corrected here) is that the motivation for automated discovery was a seamless user experience. Asking the user for the location of her identity provider, discovery service, calendar service or whatever was seen as a bump in the road, rather than user empowerment. What we're seeing now is a lot of thinking around how we can combine ideas of user identifiers (URLs or i-names) with SAML 2.0 for SSO and ID-WSF 2.0 for Web services. For example, YADIS/SAML or OpenID/ID-WSF.

In any case, user privacy, consent and control has always been foremost - hence all the work on defining how a user can consent to attributes being shared between providers [PDF], not to mention security and privacy [another PDF, I'm afraid].

Tuesday May 01, 2007

Liberty Alliance Cheaper, More Open

Just back from the Liberty Alliance plenary meeting in Brussels, Belgium. Lots of interesting stuff afoot, both in the plenary meeting itself and the associated Identity Open Space (IOS) event.

One big news item - the economics of Liberty participation just changed, radically: effective May 1, individuals can join Liberty Alliance as associate ($100) or sponsor ($250) members. Fees have also been reduced for enterprises and other organizations - see the new Membership Matrix (PDF) for details.

Also, the Technology Experts Group (TEG) mailing list is now publicly viewable. Paul explains some of the rationale. TEG is the powerhouse of the Liberty Alliance (no offense to Public Policy, Business and Marketing or any of the other expert groups!), turning market requirements into specifications; this move makes that mechanism completely transparent.

Looks like the trend towards openness and participation is spreading!

Wednesday Feb 14, 2007

David Goldsmith - Federation TV Star!

Thanks to Charles for this pointer (and to Dennis for pointing it out): David Goldsmith does a great job in this video explaining the problems inherent in the proliferation of online identities and how federation and Sun's product line (Sun Java System Access Manager and Sun Java System Federation Manager) address them. After working through a couple of real-world examples, David goes on to provide useful definitions of common federation buzzwords, such as 'circle of trust', 'identity provider' and 'service provider'. Well worth watching if you want to get up to speed quickly! Click here for the video.

Monday Feb 12, 2007

Slides from my RSA Conference session: "SOA-401 - Federated SOA: Harmonizing ID Security and Web Services"

I just uploaded the slides from my RSA Conference presentation last week: Federated SOA: Harmonizing ID Security and Web Services.

A few words of explanation on the opening slides... Sara Gates was originally booked to present in this slot. As you almost certainly already know, Sara left Sun a little while ago, and I inherited her slot. So, my opening gimmick was to introduce myself as Sara and then say "Of course, I'm not Sara, you can see and hear that, but how could a Web service tell the difference?". It was spoilt a little on the day by the RSA Conference announcer introducing me as Pat Patterson, but I made the point that if I had tried to introduce myself as Sara...

Anyway, in the presentation, I start from the position of unprotected web service interactions, working through transport-layer security via TLS/SSL to point-to-point message-layer security to Liberty Alliance's Identity Web Service Framework (ID-WSF), pointing out the different properties of each level. The session was recorded - I'm not sure if the recording will be publicly available, but, if so, I'll update this entry with a URL when it goes online.

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.

...and...

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!

Speaking at RSA Conference on Friday Feb 9 2007

I'll be speaking at the RSA Conference on Friday at 9am in Gold Room 310 on Federated SOA: Harmonizing ID Security and Web Services. I'll be looking at the role of identity in Web services, from the very basics of transport-level security to the Liberty Alliance's Identity Web Services Framework (ID-WSF), and how these are realized in Sun Java System Access Manager and Sun Java System Federation Manager. Do come along and say "Hi!"

You might also be interested in Eve Maler and Brett McDowell's session Federated Identity: Evolving Past Industry Strife - Eve and Brett will be talking about the Liberty Alliance's current course and roadmap for the future.

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