Crowd vs SAML vs Liberty Alliance vs OpenID vs CAS vs Shibboleth
Recently I picked up the blog post ‘The Wisdoms of Crowd?’ which talks about the lack of integration with Shibboleth which is an Internet2 single sign-on security framework.
At Atlassian we are constantly on the lookout for feedback so I am excited to get such a well documented analysis and critique of our product.
As the CEO of Authentisoft and now product manager of Crowd — one of the most popular questions asked by people “in-the-knowâ€? about single sign-on and identity management products is do you support technology “Xâ€?, which generally leans towards one of the SAML specifications.
Looking at our FAQ:
Crowd does not currently support SAML or Liberty Alliance.
SAML is a standard that was developed by several large companies for federated identity management. Similarly, Liberty Alliance is a consortium formed to develop and define federated identity management standards and protocols.
In our experience, for the vast majority of businesses who wish to enforce single sign-on, these standards are too complex to be truly practical. The breadth of understanding, deployment and support of these large frameworks are beyond the scope of most developers’ needs or their ability to manage. Most developers and IT managers need a solution that is simple and cost effective to deploy. Crowd was developed as a practical, simple, and secure alternative for identity management and single-sign on across an unlimited number of web-based applications.
It is true that we currently do not support SAML like technologies.
The Shibboleth feature request has caught my close attention because of the Confluence touch points referred to in the article. Atlassian is very much focused to make sure that the academic industry is satisfied and continues to find value in Confluence.
I have looked at Shibboleth and other Internet2 technologies in the past. While Shibboleth seems to be very fine tuned, I seem to have more stock in CAS which has an even larger following of academic adopters and even appears to have some integration points with Shibboleth.
The thing I like about CAS are the broad number of applications the framework integrates with:
• uPortal
• BlueSocket
• TikiWiki
• Mule
• Liferay
• Moddle
Currently the way we are driving feature development is around the number of applications and directories that we can integrate with technically while having friendly licensing.
In my own experience, people adopt things based on the perceived pain of adoption. The easier something is to deploy and integrate with the more that people will use it.
This is where Crowd fits in.
Right now we are focused internally on developing connectors for the applications and directories people already use and love. It seems to me that evaluators use a checklist of supported applications and then focus on how hard will it be to integrate their own applications with the framework.
Looking at technologies like SAML and Liberty Alliance I am challenged to think that adoption of these technologies technically will extend beyond large organizations. Even more so I wonder how well will these technologies will work with another implementation of the same specification.
Crowd is designed to be an agile, easy and cost affective to implement with world-class support Atlassian is known for. New technologies (even SAML, CAS) can be adapted integrate with Crowd in just a few short hours.
As an product manager I want do not want to turn away customers if I can prevent it – and certainly adding features is the number one way to drive new customers and increase license renewals which is why we will always keep things like Shibboleth on the radar as possible features to add support for.
One of the technologies we are keeping a close eye on is OpenID, which appears to have a large following commercially and with popular websites we already use. You can follow these feature request through our JIRA issue tracker:
Mikael Gueck said,
December 17, 2006 @ 8:55 pm
Standards-based authentication is the one area where it’s not a good idea to try to save money, since the initial setup costs are a fraction of the long-term integration costs.
Miles Metcalfe said,
December 18, 2006 @ 7:03 am
As of Shibboleth version 1.3, Shibboleth doesn’t provide an authentication mechanism. Shibboleth 2.0 will be SAML 2.0 compliant (and, as such, should pretty much interoperate with any future SAML 2.0 compliant versions of Liberty). An attractive “intermediate” use for Crowd would be inside the Location block of a Shibboleth IdP. This way, Crowd could provide the actual sign on. For Crowded web-apps, nothing would change, but for Shibbolised web-apps the Crowd sign-on would be sufficient to provide the Shibboleth identity. In fact, this scenario is where CAS currently fits in. Typically, within an institution, CAS provides Web ISO. The CAS sign-on is also the authentication Location for the institution’s Shibboleth IdP, so, once a student or a member of faculty has signed on to CAS, they can also access Shibbolised third party content (at publishers’ sites, or at other institutions in their Federation) without signing on again.
Once Shibboleth 2.0 is deployed - I imagine this is a good 6 months hence for early adopters - systems like CAS are likely to become deprecated, as Shibboleth itself will take care of authentication. I don’t see this being bad news for Crowd, though, as Crowd could provide a central point of profile maintenance and personalisation (I believe this is will prove a bigger and bigger deal in institutions as more and more students arrive at universities immersed in web-applications, and bring with them expectations formed by commercial web-applications). If Crowd is SAML 2.0 compliant, it could drop into straight Shibboleth infrastructure.
Actually, JISC, BECTA and the UK Federation don’t insist on Shibboleth, so much as SAML compliance. (As an aside, JISC and BECTA cover all UK universities, FE colleges and schools - every institution in the United Kingdom, making the UK Federation potentially the biggest access management federation in the world). Essentially, an IdP in the UK Federation has to provide the following attributes (from the eduPerson object class): eduPersonScopedAffiliation, eduPersonTargetedID, eduPersonPrincipalName, eduPersonEntitlement, but the current roadmap is, in effect, Shibboleth 2.0 - here’s a link to the Federation’s technical documents: http://www.ukfederation.org.uk/library/uploads/Documents/technical-recommendations-for-participants.pdf.
I quite agree that it is a challenge to imagine how Shibboleth is going to be implemented by smaller HE/FE institutions and schools. To an extent, the UK Federation is a political move to compel organisational changes within institutional IT departments, and, although I am a great supporter of what an access management federation can offer UK faculty and learners, I am less convinced about the chosen approach. However, we must face the world as we find it. As membership will eventually be inevitable, I have no doubt “out-sourced” IdPs will seize the opportunity to offer beleaguered IT managers a “solution”.
I’m pretty optimistic that Liberty and Shibboleth will interoperate by the time they both support SAML 2.0 - Sun historically have good links with HE, and, in any case, I doubt they want to cede all the advantage to Microsoft and ADFS.
Scott Cantor said,
December 18, 2006 @ 9:59 am
I’m biased on the general subject of SAML (and Shibboleth) for reasons that are pretty obvious (google my name), but the idea that SAML is only for large organizations is ridiculous. It’s an open standard for federated SSO, that’s it. There’s nothing all that complex about it until you actually start dealing with the fact that SSO is complex and people demand a lot of features from those systems. If you prefer to ignore those features, you get a simpler system.
Deploying SAML isn’t that hard unless you include all the parts that actually matter, namely authentication, IdM, and attributes, none of which are possible to avoid with other systems. I see LDAP in your Crowd diagram. LDAP is harder to deploy than any SAML-based product, and it’s not even close. That’s not a criticism of LDAP or Crowd, just pointing out that the hard part isn’t SSO, and that’s all SAML does.
Also, the fact that Confluence even *cares* what system is being used is the real problem here. Web applications that know anything about authentication are broken. All of them. When you design web apps properly to rely on the web server for identity, you can swap in any SSO system and the application never even knows it.
Finally, FWIW, we do have some decent code that integrates the authn, registration, and provisioning process in Confluence with Shibboleth. More about it here:
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/ShibbolizedConfluence
Steve Carmody said,
December 18, 2006 @ 1:32 pm
Like Scott, I have some involvement with the Shibboleth project; you should keep that in mind while reading my comments. I have a number of concerns about Cloud, as I currently understand it:
1) Suddenly, a significant percentage of campus based projects draw their membership from multiple institutions (eg the rise of “Virtual Organizations”). Campuses used to have to issue local credentials to all of the “foreign” members of the project. Federated Identity between campuses allows the “foreigners” to use their local campus credentials when authenticating, and allows the campus hosting the services supporting the project to avoid issuing lots of guest ids that they then have trouble tracking. If the “foreigner”s campus doesn’t yet run Federating software, they can get an identity at http://protectnetwork.com/ .
We’re also seeing a growing number of comercial sites interested in the Federated approach, since it allows them to stop storing userids and passwords — thus, they no longer have a “crown jewel” for hackers to go after. However, they can continue to offer “personalization” at their site by leveraging the targetedId attribute.
As I understand Crowd, you’d expect us to continue to create guest ids and issue credentials, and perhaps put them in some equivalent of a “customer db”?
We’re looking for a single Web SSO package that will support both intra-campus and inter-campus users.
2) The family of Shib-enabled applications continues to grow (including many of he CAS-ified applications that you list):
https://wiki.internet2.edu/confluence/display/seas/Home
3) Google is offering SAML-based Web SSO access to their Google Apps for Education Package (eg campus branded email but served from Google).
http://www.google.com/a/edu/
Their product manager has authorized us to say “Google is dedicated to supporting open standards, and are talking with Shibboleth about integration around this.”
I guess Google feels that SAML isn’t too hard for the campuses …
4) How will the smaller schools deploy SAML? Possibly using software like the gateway that the K12 environment in the UK will be using to deploy SAML to 30,000 K12 schools in that country…. talk about a young audience you’d like to get addicted to your product….
5) Crowd seems to include both authentication and authorization functionality. (The authz functionality I’m referring to is support for static nested groups.) Why won’t you let my campus use the SSO mechanism that we’ve already deployed, and still take advantage of your new groups support?
Alistair Young said,
December 19, 2006 @ 4:23 am
I’d like to come from the other side of the fence in that Scott is a SAML architect and therefore bound to think SAML is easy. I just wrote a pure Java Shibboleth implementation and had to learn SAML from scratch and it’s not easy if you’ve never been exposed to the concepts that SAML lays bare.
LDAP is far easier to deploy than a SAML based product as most people deploy AD or eDirectory which are commercial grade systems and designed to be easy to install and work with and most places have staff who are trained to support those systems. Just about everyone has an LDAP directory of some sort.
Just about no-one has an IdP.
It’s a great concept being able access resources based on who or what you are, not having to bother with having accounts maintained in a remote system and being able to decide who you talk to, until you realise the infrastructure you need to make it happen. Also, the choice of open source infrastructure is limited.
As for the comment about web applications that know about authentication being broken is ludicrous. I think what is meant is the implementation of that authentication. Whether the authentication comes from the server or application provided interface implementations is neither here nor there until you consider that server implementations differ across servers, obviously, while appliation interfaces don’t. So clearly relying on server authentication creates more work.
If someone knocks on my door, I don’t think to myself “ach the house will take care of recognising the person knocking on my door, I’ll just believe what it tells me”. 8-0
I’ve gone through the pain of shibbing quite a lot of applications and I spend a lot of time with SAML and Shibboleth and it’s still a pain as today’s applications aren’t designed to work with the concepts that SAML provides and as almost no-one uses Shibboleth just now, the apps aren’t too concerned about integrating with it, so even more work is required to keep your local shibbed versions up to date with the current releases of those applications.
If you step outside the document publishing scenario where there’s one SP and a load of IdPs and into machine to machine (which isn’t Shibboleth) and applications, your staff skillset has to skyrocket overnight and you find yourself neck deep in other people’s source code.
Whereas with LDAP you just send your staff on a course, with Shibboleth you need programmers, xml experts, PKI experts, philosophers and laywers. Shibboleth is about exposing your resources to the world. Traditionally that was done via guest accounts in your LDAP system and someone saying “sign here”.
Justen Stepka » OpenID Trumps SAML and Liberty Alliance said,
March 12, 2007 @ 12:55 am
[…] By now you may be thinking, “Where are you going with all of this, because you are telling me nothing new.â€? This leads me back to a point I made about Atlassian’s Crowd product in a previous blog: […]