Pursuant to my question on alleviating the password explosion, I've contacted some of the services to whom we are paying money to access their websites to ask if we could authenticate our own users, and some of them said yes and send me specs on how to do so. (One of the sites called such a system a page a "portal"; I've never heard the term used in quite that way.)

It is simple enough that I am tempted to roll my own. The largest complication is that one site wants us to store a key for every user in our database (and I think the LDAP database makes sense) after their initial login. So, non-trivial, but doable.

The nature of these sorts of tasks, I expect, is that if they start out small and simple, they don't end that way. There must be some software that addresses this that is readily extended, surely.

In my searching, I've come across:

[Wow, gee. I'd missed some of those in my previous searches! The wikipedia page on Central Authentication Services is useful, and the section on Alternatives to OpenID makes it look like there is a lot of choice.]

Can anyone recommend any of these, or suggest ones to avoid?

Internally, we are authenticating using Apple's Open Directory [ == OpenLDAP + Kerberos + Password Server (which, I believe, == SAML) ].

As far as extending/tweaking/advanced configuration of a system, I am able to program in Python, C++, can do some basic PHP, and may be able to remember some Java. Looks like I need to pick up Ruby at some point.

Addendum: I would also like users to be able to change their passwords over the web (and for certain users to change passwords of other users).


My impression (based on a recent conference about cloud computing) is the three players with the "buzz" and support would be OpenID, SAML, and Information Cards.

OpenID is more useful for individuals, being a bit easier to use/install/whatever, with some compromises in security to make that "easier" happen.

SAML and Information Cards are more enterprise oriented with strong security.

All three handle your identity management needs, but I don't think OpenID is quite at real SSO like the other two, i.e. if I log in to a web site using OpenID it won't automatically log me in to the other web sites I've authorized.

SAML is backed by Google and friends so if you use Google Apps, Salesforce.com, etc. it's an easy choice. Information Cards are more or less Microsoft origin and (I think) used by MSN Live.

There are Python based OpenID and SAML libraries but I haven't found any for Information Cards yet (well ok, not really looking :)

  • Shibboleth also uses SAML under the hood. – David Pashley Jun 12 '09 at 18:38

Shibboleth is only really applicable to securing access to resources available via HTTP. It is also designed to deal only with a trusted web of sites, unlike OpenID, which is designed for untrusted sites to authenticate. I'd suggest that OpenID is significantly simpler than Shibboleth to implement.

  • Shibboleth sounds like it addresses the problem I am trying to solve much better than OpenID does. Basically, I need a launching-off page from which our users can go to certain known sites. I don't know that I'd fully trust those sites, but I can't say I'd consider them untrustworthy, either. – Clinton Blackmore Jun 12 '09 at 16:00
  • Yes, I suspect it would be, but I think it would be a harder sell for your suppliers to implement Shibboleth authentication. Sadly shibboleth tends to be a little fiddly to get right, especially if you've never used it before. It took me a couple of months to understand it. – David Pashley Jun 12 '09 at 18:41

I've used both Shibboleth and SimpleSAML and worked on extensions for both.

At our office, we use a customised version of SimpleSAML php to provide an IDP to Google Apps. So, our staff can login to Google Apps using the same credentials as the local office LDAP.



  • very powerful in terms of features (if you can figure out how to configure them).
  • takes a while to wrap your head around the architecture and setup - everything is an XML.
  • documentation requires a bit more digging to get at the information.
  • IDP written in Java. SP is an Apache module.


  • easy to use/setup - you can get it up and running following their documentation in minutes.
  • very easy to customise i.e. lots of example modules and documentation is easy to follow.
  • has more esoteric features such as YubiKey support.
  • SP/IDP written in PHP.

In our ideal setup, we would use a Shibboleth SP with a SimpleSAML IDP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.