SAML Single Sign-On (SSO) Service for Google Apps – Using SimpleSAMLPHP and ModifiedFreeRadius
Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.
Google Apps offers a SAML-based Single Sign-On (SSO) service that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the SAML model, Google acts as the service provider and provides services such as Gmail and Start Pages. Google partners act as identity providers and control usernames, passwords and other information used to identify, authenticate and authorize users for web applications that Google hosts. There are a number of existing open source and commercial identity provider solutions that can help you implement SSO with Google Apps.
It is important to note that the SSO solution only applies to web applications. If you want to enable your users to access Google services with desktop clients such as Outlook—for example, providing POP access to Gmail using Outlook—you will still need to provide your users with usable passwords and synchronize those passwords with your internal user database using the Provisioning API. In addition when sychronizing your passwords, it is useful to understand how users are authenticated using the admin control panel login URL.
The Google Apps SSO service is based on the SAML v2.0 specifications. SAML v2.0 is supported by several widely known vendors.
Understanding SAML-based SSO for Google Apps
The following process explains how a user logs into a hosted Google application through a partner-operated, SAML-based SSO service.
Figure 1, shown below, illustrates the process by which a user logs in to a Google Apps application, such as Gmail, through a SAML-based SSO service. The numbered list that follows the image explains each step in more detail.
Note: Before this process takes place, the partner must provide Google with the URL for its SSO service as well as the public key that Google should use to verify SAML responses.
Figure 1: Logging in to Google Apps using SAML
This image illustrates the following steps.
- The user attempts to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
- Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s SSO service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection.
- Google sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner’s SSO service.
- The partner decodes the SAML request and extracts the URL for both Google’s ACS (Assertion Consumer Service) and the user’s destination URL (RelayState parameter). The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.
- The partner generates a SAML response that contains the authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner’s public and private DSA/RSA keys.
- Google’s ACS verifies the SAML response using the partner’s public key. If the response is successfully verified, ACS redirects the user to the destination URL.
- The user has been redirected to the destination URL and is logged in to Google Apps.
Introduce to simpleSAMLphp and How to implement SSO Within it
1. simpleSAMLphp news and documentation
This document is part of the simpleSAMLphp documentation suite.
- List of all simpleSAMLphp documentation
- Latest news about simpleSAMLphp. (Also conatins an RSS feed)
- simpleSAMLphp homepage
This article assumes that you have already read the simpleSAMLphp installation manual, and installed a version of simpleSAMLphp at your server. In this example we will setup this server as an IdP for Google Apps for Education:
config.php, and enable the SAML 2.0 IdP:
'enable.saml20-idp' => true, 'enable.shib13-idp' => false,
For test purposes, you can skip this section, and use the certificate included in the simpleSAMLphp distribution. For a production system, you MUST generate a new certificate for your IdP.
Here is an example of an openssl command to generate a new key and a self signed certificate to use for signing SAML messages:
openssl req -newkey rsa:2048 -new -x509 -days 3652 -nodes -out googleappsidp.crt -keyout googleappsidp.pem
The certificate above will be valid for 10 years.
Here is an example of typical user input when creating a certificate request:
Country Name (2 letter code) [AU]:ID State or Province Name (full name) [Some-State]:Lampung Locality Name (eg, city) :Bandar Lampung Organization Name (eg, company) [Internet Widgits Pty Ltd]:UPT-PUSKOM Organizational Unit Name (eg, section) : Common Name (eg, YOUR name) :sso.unila.ac.id Email Address :firstname.lastname@example.org Please enter the following 'extra' attributes to be sent with your certificate request A challenge password :xxx An optional company name :xxx
Note: simpleSAMLphp will only work with RSA and not DSA certificates.
The next step is to configure the way users authenticate on your IdP. Various modules in the
modules/ directory provides methods for authenticating your users. This is an overview of those that are included in the simpleSAMLphp distribution:
- Authenticate against a list of usernames and passwords.
- Automatically log in as a user with a set of attributes.
- Authenticates an user to a LDAP server.
For more authentication modules, see SimpleSAMLphp Identity Provider QuickStart.
In this guide, we will use the
exampleauth:UserPass authentication module. This module does not have any dependencies, and is therefore simple to set up.
After you have successfuly tested that everything is working with the simple
exampleauth:UserPass, you are encouraged to setup simpleSAMLphp IdP towards your user storage, such as an LDAP directory. (Use the links on the authentication sources above to read more about these setups.
ldap:LDAP is the most common authentication source).
exampleauth:UserPass authentication source is part of the
exampleauth module. This module isn’t enabled by default, so you will have to enable it. This is done by creating a file named
On unix, this can be done by running (from the simpleSAMLphp installation directory):
The next step is to create an authentication source with this module. An authentication source is an authentication module with a specific configuration. Each authentication source has a name, which is used to refer to this specific configuration in the IdP configuration. Configuration for authentication sources can be found in
In this example we will use the
example-userpass, and hence that section is what matters and will be used.
<?php $config = array( 'example-userpass' => array( 'exampleauth:UserPass', 'student:studentpass' => array( 'uid' => array('student'), ), 'employee:employeepass' => array( 'uid' => array('employee'), ), ), ); ?>
This configuration creates two users –
employee, with the passwords
employeepass. The username and password is stored in the array index
student:studentpass for the
student-user. The attributes (only
uid in this example) will be returned by the IdP when the user logs on.
If you want to setup a SAML 2.0 IdP for Google Apps, you need to configure two metadata files:
This is the configuration of the IdP itself. Here is some example config:
// The SAML entity ID is the index of this config. Dynamic:X will automatically generate an entity ID (Reccomended) '__DYNAMIC:1__' => array( // The hostname of the server (VHOST) that this SAML entity will use. 'host' => '__DEFAULT__', // X.509 key and certificate. Relative to the cert directory. 'privatekey' => 'googleappsidp.pem', 'certificate' => 'googleappsidp.crt', 'auth' => 'example-userpass', )
Note: You can only have one entry in the file with host equal
__DEFAULT__, therefore you should replace the existing entry with this one, instead of adding this entry as a new entry in the file.
In the (
saml20-sp-remote.php) file we will configure an entry for Google Apps for education. There is already an entry for Google Apps in the template, but we will change the domain name:
/* * This example shows an example config that works with Google Apps for education. * What is important is that you have an attribute in your IdP that maps to the local part of the email address * at Google Apps. E.g. if your google account is foo.com, and you have a user with email email@example.com, then you * must set the simplesaml.nameidattribute to be the name of an attribute that for this user has the value of 'john'. */ 'google.com' => array( 'AssertionConsumerService' => 'https://www.google.com/a/unila.ac.id/acs', 'NameIDFormat' => 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', 'simplesaml.nameidattribute' => 'uid', 'simplesaml.attributes' => false );
You must also map some attributes received from the authentication module into email field sent to Google Apps. In this example, the
uid attribute is set. When you later configure the IdP to connect to a LDAP directory or some other authentication source, make sure that the
uid attribute is set properly, or you can configure another attribute to use here. The
uid attribute contains the local part of the user name.
For an e-mail address
uid should be set to
You should modify the
AssertionConsumerService to include your Google Apps domain name instead of
For an explanation of the parameters, see the SimpleSAMLphp Identity Provider QuickStart.
Start by logging in to our Google Apps for education account panel. Then select “Advanced tools”:
Figure 1. We go to advanced tools
Then select “Set up single sign-on (SSO)”:
Figure 2. We go to setup SSO
Upload a certificate, such as the googleappsidp.crt created above:
Figure 3. Uploading certificate
Fill out the remaining fields:
The most important field is the Sign-in page URL. Set it to something similar to:
using the hostname of your IdP server.
You must also configure the IdP initiated Single LogOut endpoint of your server. The RelayState parameter of the endpoint is the URL where the user is redirected after successfull logout. Recommended value:
again, using the host name of your IdP server.
The Sign-out page or change password url can be static pages on your server.
The network mask determines which IP addresses will be asked for SSO login. IP addresses not matching this mask will be presented with the normal Google Apps login page. I think you can leave this field empty to enable authentication for all URLs.
Figure 4. Fill out the remaining fields
Before we can test login, a new user must be defined in Google Apps. This user must have a mail field matching the email prefix mapped from the attribute as described above in the metadata section.
Go to the URL of your mail account for this domain, the URL is similar to the following:
replacing the last part with your own google apps domain name.
Make sure that your IdP server runs HTTPS (SSL). The Apache documentation contains information for how to configure HTTPS.
Make sure you have replaced the default certificate delivered with the simpleSAMLphp distribution with your own certificate.
If you need help to make this work, or want to discuss simpleSAMLphp with other users of the software, you are fortunate: Around simpleSAMLphp there is a great Open source community, and you are welcome to join! The forums are open for you to ask questions, contribute answers other further questions, request improvements or contribute with code or plugins of your own.
12. SimpleSAMLPHP with Database Support (MySQL)
root@apps:/var/www/modules/sqlauth# ls default-enable docs lib root@apps:/var/www/modules/sqlauth# touch enable
Read the manual of using this module
`sqlauth:SQL` ============= This is a authentication module for authenticating an user against a SQL database. Options ------- `dsn` : The DSN which should be used to connect to the database server. Check the various database drivers in the [PHP documentation](http://php.net/manual/en/pdo.drivers.php) for a description of the various DSN formats. `username` : The username which should be used when connecting to the database server.
`password` : The password which should be used when connecting to the database server. `query` : The SQL query which should be used to retrieve the user. The parameters :username and :password are available. If the username/password is incorrect, the query should return no rows. The name of the columns in resultset will be used as attribute names. If the query returns multiple rows, they will be merged into the attributes. Duplicate values and NULL values will be removed. Examples -------- Database layout used in examples: CREATE TABLE users ( username VARCHAR(30) NOT NULL PRIMARY KEY, password TEXT NOT NULL, name TEXT NOT NULL, email TEXT NOT NULL ); CREATE TABLE usergroups ( username TEXT REFERENCES users (username) ON DELETE CASCADE ON UPDATE CASCADE, groupname TEXT, UNIQUE(username, groupname) ); Example - simple setup, PostgreSQL server:
'sql-exampleorg' => array( 'sqlauth:SQL', 'dsn' => 'pgsql:host=sql.example.org;port=5432;dbname=simplesaml', 'username' => 'userdb', 'password' => 'secretpassword', 'query' => 'SELECT username, name, email FROM users WHERE username = :username AND password = :password', ), Example - multiple groups, MySQL server: 'sql-exampleorg-groups' => array( 'sqlauth:SQL', 'dsn' => 'mysql:host=sql.example.org;dbname=simplesaml', 'username' => 'userdb', 'password' => 'secretpassword', 'query' => 'SELECT users.username, name, email, groupname AS groups FROM users LEFT JOIN usergroups ON users.username=usergroups.username WHERE users.username = :username AND password = :password', ), Example query - MD5 of salt + password, stored as salt + md5(salt + password) in password-field, MySQL server: SELECT username, name, email FROM users WHERE username = :username AND SUBSTRING(password, -32) = MD5(CONCAT(SUBSTRING(password, 1, LENGTH(password) - 32), :password)) Example query - MD5 of salt + password, stored as salt + md5(salt + password) in password-field, PostgreSQL server: SELECT username, name, email FROM users WHERE username = :username AND SUBSTRING(password FROM LENGTH(password) - 31) = MD5(SUBSTRING(password FROM 1 FOR LENGTH(password) - 32) || :password)
Don’t forget to inform SAML NameIDAttribute according to field email on MySQL DB
$metadata['google.com/a/unila.ac.id'] = array( 'AssertionConsumerService' => 'https://www.google.com/a/unila.ac.id/acs', 'spNameQualifier' => 'google.com', 'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:email', 'simplesaml.nameidattribute' => 'email', 'simplesaml.attributes' => false );
### RELATED CRITICAL FILES TO SERIOUSLY EDITED:
Voila, and it will Works….
Demikian Tulisan menjelang Buka Puasa hari ini tanggal 25-Juli-2013, mudah-mudahan ada manfaatnya
saya mau jemput istri dulu.