Overview of Single Sign-On      

The purpose of this guide is to document some of the most common Single Sign-On use cases in order to integrate Google Apps at a school or university.

The areas of focus will be:

1. Overview of Basic Concepts for SSO

A brief overview of the basic terms and concepts used in Single Sign-On environments.

2. Getting Started

What to think about before you get started, and how to make sure you'll be ready.

3. Installing OpenAM

OpenAM is an open source access management, entitlements and federation server platform which supports a variety of identity providers and solution providers out of the box.

4. Configuring Identity Providers

You can have your users stored in Google Apps, LDAP, a database, or other systems. Learn how to integrate each one with OpenAM.

5. Configuring Service Providers

Using SAML and OAuth 2.0, allow your existing applications to authenticate against your identity provider.

6. Platform Interconnection

Connect the final pieces and set policies within OpenAM.

Please note: Additional technical resources on deploying Google Apps and Chromebooks, as well as Networking best practices can be found on at deployment.googleapps.com.

1. Overview of Basic Concepts for SSO

• SAML: Security Assertion Markup Language
  XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider
  

• OAuth2
  Is an open standard for authorization that provides to client applications a 'secure delegated access' to server resources on behalf of a resource owner. It focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
  

• IdP: Identity Provider
  Entity who grants access. This is the canonical system where your users' account and authentication information is stored.
  

• SP: Service Provider
  Services that users want to log in to. In SSO, these check users against the IdP in order to grant access.
  

• LDAP: Lightweight Directory Access Protocol
  Standard application protocol for accessing and maintaining distributed directory information services like Active Directory, Novell eDirectory, OpenLDAP, OpenDS, OpenDJ, etc.

• Access Management Solutions
  Platforms that works as a server of the principal SSO technologies (SAML, OAuth2) in which SPs will connect, and works as a client of the principal IdP (LDAP, Active Directory, Database, RADIUS, etc).

These are some common examples of each one:

OpenAM

In this guide we will use OpenAM as the access management solution. OpenAM is an “all-in-one” access management solution that can be used with both SAML and OAuth2. It works as an interface that connects SPs to a variety of IdPs (see full list here). This guide shows how to interconnect Google Apps as SP (via SAML) and as IdP (via OAuth2) using OpenAM as a bridge.

.

2. Getting Started

Things to think about before you begin

Planning the SSO solution

1. Identify what IdPs and SPs are present at your institution
   Think about all of the systems where you maintain a record or account per user. How many passwords could an individual user have for different systems? Each place application where individual user data or settings are stored is a potential Identity Provider or Solution Provider for your SSO system.
   

2. Choose a single canonical Identity Provider
   It is important to reduce all IdPs down to a single one, so that there is only one place where you need to worry about setting passwords and authentication. Choose a system that is flexible enough to keep a record for all of your users of different types, and one that is secure -- avoid storing passwords in plaintext, and consider offering 2-factor authentication for users.
   All of your other systems will become Solution Providers.
   

3. Identify SAMLv2/OAuth2 modules for your existing Solution Providers
   Many applications already offer a way to authenticate against third-party identity providers using a common open standard. Read the documentation and look for the best way to integrate them into the system.
   

4. Put on a diagram the IdP and the SPs connecting with which technology (SAML/OAuth2).
   This final step summarizes all of the information you've collected and will help you make sure you haven't left anything out.

Setting up a test domain

We recommend that you set up a test domain where you can experiment with the setup before rolling it out for real. This can be a subdomain of your institution's main domain, or a totally separate one you use just for testing.

You'll need to be able to change DNS settings and create subdomains, have a linux server able to host web applications for configuration and management, and also have a Google Apps account configured for the domain. For testing SSO, you can use Google Apps for Education and Google Apps for Business interchangeably, so it does not matter which edition your test account is on

3. Installing OpenAM

OpenAM can be installed on every Operating System that supports Java. You will need a (sub)domain to host the web-based administration interface, as well as a local or remote server running Tomcat 7 to host the app itself.

You can download OpenAM here and find installation instructions here. For a more detailed walkthrough of the steps that we used to install on Ubuntu, see the guide here.

4. Configuring Identity Providers

Configuring Google Apps as an Identity Provider

This option allows you to use the institution's Google Apps domain as the primary Identity Provider for logging in to other systems. This gives your users a reliable and familiar login page, and allows you to take advantage of security features like 2-factor authentication for all of your users.

In order to do this, add Google as a new OAuth 2.0 authentication option in OpenAM's Access Control settings. To generate the right credentials, you will need to make a new project at http://console.developers.google.com and generate the Client ID and Client Secret on the APIs & auth > Credentials page.

More detailed instructions here and official instructions.

Configuring LDAP server as an Identity Provider

Many institutions already have an LDAP server set up with users' account information, and it is easy to make this the central identity provider within OpenAM. On the "Access Control" > "Authentication" page of OpenAM's web admin, you can create an LDAP module and fill in the LDAP parameters.

Some common considerations:

• On “Bind User” type a complete path (with cn and dc parameters), example: cn=admin,dc=sso,dc=appsedudemo,dc=com

• On “Attribute used to retrieve User Profile”: uid

• On “Attributes used to search ...”: Add uid and mail.

• Within OpenAM on "Authentication" > "Core" > "All core settings", change "User profile" to "Dynamic"

• Be sure that you have users on LDAP with uid parameter as the username in Google Apps, and mail value the same as the user's full email.

More detailed instructions here.

Configuring a Database as an IdP

OpenAM supports authentication against most databases as long as you can connect to them via JDBC.

Create a new JDBC authentication instance on OpenAM's Access Control page and fill in your database parameters. You can control the exact columns and query used to pull the username and password information for authentication, so you should be able to use it with any schema you have already.

More detailed instructions here.

.

5. Configuring Service Providers

Configuring Google Apps as SP via SAML

If the institution already has an identity provider they are satisfied with, it is also easy to set up Google Apps as a solution provider so that anyone logged in to their institutional identity will be able to access Gmail and other apps without needing to authenticate separately to Google.

Within OpenAM web admin, you can use the "Common Tasks" tab to configure a Circle of Trust and then configure Google Apps. This will generate links and a certificate for SSO which you can enter in the "Security" > "Advanced" > "Set up single sign-on (SSO)" section of the Google Apps admin console (http://admin.google.com).

More detailed instructions here.

Configuring Moodle as a SP via OAuth2

Moodle is a common learning management system (LMS) used by many universities. It offers an OAuth2 plugin that you can easily connect to OpenAM for a seamless signon from Google Apps or any other Identity Provider.

In the OpenAM Web admin, Click on “Access Control” > "/ (Top Level Realm)" > “Authentication” > “Module Instances”. Create a new OAuth2 instance for Moodle.

In the Moodle admin console, go to "Plugins" > "Authentication" > "OAuth2" (if it is disabled, enable it).

More detailed instructions here.

6. Platform interconnection

Once you have Identity Providers and Service Providers set up within OpenAM, you can configure connections to permit logins to the services.

As an example, if you're using OpenLDAP as the IdP and Google Apps as the SP, you need to go to "Access Control" > "/ (Top Level Realm)" > "Authentication" > "Authentication chaining" > "New". Set a name and add your LDAP module, then update the "Organization Authentication Configuration" section on the Core section to include your created chain name.

More detailed instructions here.