If you have been around IWU for a while you will have noticed how more and more systems are getting connected to the NetID system.  This is great for everyone.  From my end, there is only the one place where user accounts can be messed up (excluding the few systems which are in no way hooked up to LDAP, but that is hopefully coming…. hopefully).  From your end, there is just the one username and password to remember.  But is the project complete with just LDAP?

LDAP (Lightweight Directory Access Protocol) support is available on almost every piece of Enterprise grade software.  This is all well and good, but all that does is provide Singular Sign On.  One username and password that you must enter into everything.  This is close to a Single Sign On but also very far from the goal.  What then is Single Sign On?

Single Sign On means, if you visit Ames, login to the computer there, you should automatically have access to everything that you should have access to.  You should just be able to launch a web browser, point it at my.iwu.edu and automatically get access to your email - without typing a password.  For a real Single Sign On, you should only have to login once, not only have one username and password.

What am I doing about it?  I have just built a test system that will be able to connect a few services that were not able to be connected to LDAP.  This helps push forward the Singular Sign On.  It also supports GSSAPI, the foundational protocol for Kerberos v5.  Kerberos V5 is a secure way of doing Single Sign On.  In another post on this Blog I mention the Microsoft way of performing Single Sign On over SMB.  It is not secure.  Kerberos is very well secured.  In the end Kerberos is the only secure Single Sign On system we understand enough to implement.  As an added bonus this system will also speak SASL.  SASL is just a method of protecting passwords in transmission.  One of the supported SASL methods is GSSAPI.  The primary motivator for this project was SMB support.  SMB is the official name for Microsoft’s file sharing protocol.  Support for that was built in, and designed in such a way that it too can do GSSAPI.  Lastly, it would be a shame to lose the LDAP support that we have all grown to love.  So LDAP is included, but this LDAP server supports GSSAPI as well.  All together this gives, under a single username and password, LDAP, SMB, Kerberos, and SASL based logins, each of which is GSSAPI enabled.

What does this really mean?  When this comes on line we should be able to start fostering a GSSAPI friendly environment, this then can give us a secure Single Sign On and a Singular Sign On too.  There are still some loose ends, but the testing coming in a few weeks should tie most of those up.  When it is successful, there simply is not a major protocol we are likely to bring online here that cannot be supported from that single username and password.

Yeah, but what does this really mean?  It means that, if enough applications can be configured on campus to support GSSAPI, you will start to see a day where all the university servers just magically know who you are and grant you the access you deserve after a single login.  No more logging in to login so that you can login to a service.

Technologies used: OpenLDAP - 2.4.7,  Samba 3.0.24, Heimdal Kerberos 1.0, smbk5pwd 0.0.0

Is there a next step beyond this combination?

Yes, we can add to the mix a bit of software called Shibboleth.  I am still trying to get it figured out, but once that happens it should be transparently added one day, leaving no one the wiser.  Why Shibboleth?  It is an open standard, secure, and free.  Periodically I hear mention of using Google to host our email, the price is vastly lower than what it costs us to do it ourselves, but, if we go that way, we would need a secure way of transmitting who can have IWU access to Google resources.  This is where Shibboleth comes in.  Google likes it because it is an open standard, very secure, and easy to integrate large numbers of remote sites together.  They support other access methods, but none really compare to what Shibboleth really is.  Another factor that is driving Shibboleth into the main stream is Internet2.  Internet2 has standardized on Shibboleth as its authentication system of choice.  If IWU is going to get Internet2 (which is currently a no, but that cannot last forever), we will have to decide if we are going to allow Internet2 based logins.  It seems silly to say no, but if we say yes then Shibboleth is a must.

I haven’t explored all the capabilities of Shibboleth yet, but I honestly expect it to spawn the next big thing in authentication.  Shibboleth itself seems capable of so many things, but only covers so many possible access methods.  The successor to Shibboleth will drive Single Sign On and Singular Sign On into yet another uncharted realm.  That, however, is about 10 years out.  Why wait for the next big thing when such a great one is sitting here waiting only for the time it will take to understand it.