By: Tony DePrato | Follow me on Twitter @tdeprato

SSO, or Single Sign On, is something I often discuss with school leadership, teachers, parents, and students. SSO refers to the ability for users to have one login and password that gives them access to all, or the majority of, the services they use. I have achieved this, and I would like to share the path I followed.

The Scope

The scope of SSO is very important. Many people will feel they have achieved SSO if their Google Apps account connects them to a few services. I would classify this as a very limited scope.

In the SSO implementation I am suggesting, the scope is:

1. Email and Groupware Systems/Cloud (Google Apps, Office 365, etc.)
2. School Information Systems (For example, PowerSchool)
3. School Wifi and LAN Network Access. Accessing the network with the single account. This prevents unauthorized users from simply using the network with a shared SSID.
4. Login Windows for School Owned Laptops and Desktops. This means users apply the same username and password for the school hardware.
5. Printing and copying access
6. Additional systems such as Follet Destiny, BrainPop, etc.

With this implementation, all the core IT services on-and-off campus can use, and require, the SSO. Each user uses one username and password to connect to 90% of their resources; and they simply match their username and password on systems that may not be compliant.

For the end sure, this is a transparent process.

The Heart of the Solution

Are you a Google Apps for Education School? If the answer is ‘yes’, then the answer to true SSO is a bit more complicated. Google does not offer a traditional directory service. In order to facilitate a full SSO implementation Google schools need a middle solution.

The concept is that the middle solution has permission to access and use the Google Apps accounts. Once this is enabled, the middle solution will sync and/or translate access between services. The login will either be the username(which is the first part of the email), or the full email itself. The password is managed in the middle solution.

I do not like to promote any specific services. However, for this design I made a special agreement with a company called JumpCloud. There are other services that will do the same job, and unlike traditional methods used for SSO, these cloud based solutions are easy to migrate from in the future.

If you are not a Google Apps for Education school, then odds are you do have Office 365. Microsoft now provides most of the needed features in their Azure Cloud, using Active Directory in the Cloud. This can be free, or licensed, depending on your needs.

If you do not have Google or Office365, then you probably can use any number of Open LDAP Cloud services, or you could technically build and host your our service with Amazon.

If you notice, I am staying in The Cloud. In my experience, very few schools have the in-house talent and resources to facilitate SSO using onsite servers. They can get the services to work, but the speed and quality is no where near that of the cloud based providers. I used a self-hosted solution in China for four years, and once I was able to move off-sight, the end user experience greatly improved.

Enough of the Tech Speak

If you are not working in technology, the sections above will help you immensely in speaking with your technology leadership about SSO. However, to rebound from the monotony of SSO vocabulary and processes, I would like to take a trip through the end user experience.

A new person (employee or student) joins your school. They sit down, and they activate their GMAIL.

When the GMAIL is activated, there is a message in their inbox. They open it. The message directs them to the middle solution provider. The user re-enters their password, and confirms their email.

A few minutes later they get another email, this one is for Office 365. The user opens it, and agrees to terms or service by entering their username and password.

From this point on, that username and password are now linked to all the services, including the school owned devices and network.

The initial steps can be done for new staff before they come to the school. This is an excellent time saver, and I find that new staff like this engagement. If they make a mistake, their email will always work for them. The other services are not critical until they arrive.

The student experience is a little different. I find it is best to have an initial registration process and location for new students. In this location, the WIFI network is open.

However, after they activate, they switch to their official network, and they sign-in with their new ID. Remember, there is no anonymous access. Once implementation is over, only those who are trusted members of the school can use the same networks as students and employees.

If you want to know more about creating seamless SSO experiences, or if you would like to share your own experience, please comment or email me directly, [email protected] .

Thanks for reading.