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:
A brief overview of the basic terms and concepts used in Single Sign-On environments.
What to think about before you get started, and how to make sure you'll be ready.
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.
You can have your users stored in Google Apps, LDAP, a database, or other systems. Learn how to integrate each one with OpenAM.
Using SAML and OAuth 2.0, allow your existing applications to authenticate against your identity provider.
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
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
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 ProviderThis 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 ProviderMany 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:
More detailed instructions here. Configuring a Database as an IdPOpenAM 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 SAMLIf 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 OAuth2Moodle 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. |
Home > SSO Single Sign-On >