Web-based Single Sign On
I’ve been working a bit with SAML as a method to provide web based single sign on services. If you are not familiar with this technology, SAML sits between your directory service and a web-application. In this case, SAML is connected to OpenDirectory. SAML has two components when authenticating a service. One is the Identity Provider (IdP) and the other is a Service Provider (SP). The IdP serves as the component actually responsible for verifying usernames and passwords, as well as keeping track of authenticated sessions. The SP is a module added to each web-based application in essence having the authentication component of that application connect to the authentication system of SAML.
Why is something like this useful? If you have a 3rd party application, end-users need to worry about usernames and passwords. Unless these 3rd party systems allow for a LDAP module, you typically have needed to maintain another set of names and passwords to the service. If someone is no longer employed by your organization, you now need to delete their accounts in all services. Additionally, users need to login to each session. SAML allows web-applications to leverage a common authentication system. In this case the system used is simpleSAMLphp, an open source PHP implementation of SAML.
As a real-life example, we currently utilize Google Applications and Moodle, with the idea to add in WordPress μ into the mix. Each of these applications supports a SAML authentication service. Not only does that mean all three systems can now use a common authentication source (OpenDirectory) but once a user has successfully authenticated via SAML to one service, their session is remembered and any other web-service using SAML does not need to present a login screen; rather, the already valid session is utilized. One username, one password, multiple 3rd party systems.
For our teachers, this means if they wish to create an online classroom in Moodle, students can login with their network credentials. Taking it one step further, an embedded link to a Google Doc for a homework assignment opens when clicked without the student needing to login again. Further, their assignment to write a quick blog post on WordPress is as simple as navigating to the page. Again, no additional login is required to get to this site.
The benefit to adopting a system like this is it allows for a very modular approach to service adoption. When the next application using SAML is determined, we can leverage an existing infrastructure to provide authentication services.
And now my question to you. If you are an educator, how can you see a system like this making a class project easier? If you are a techie, have you implemented a SAML solution, and if so, how has it worked for you? Anything you would change to make deployment easier?



May 12, 2010 
















Thanks for the info. I have this working somewhat. However, I used the Google Apps Directory Sync on a windows machine for syncing users. The info on SSO was awesome.
What do you do to get around the non-trusted certificate since it’s just a self-signed cert? All the browsers get annoyed by this and I can see it causing problems with students & staff.
I’m just wondering if there’s a way to install it on the computers so it doesn’t question it.
To go around the certificate issue, we actually went and purchased an SSL certificate with GoDaddy. Since we looked at using the SAML instance for other services, it was worth the investment to need to worry about individuals getting certificate messages.