Home > World Of ICT > SAML Single Sign-On (SSO) Service for Google Apps – Using SimpleSAMLPHP and ModifiedFreeRadius

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

SAML Workflow

This image illustrates the following steps.

  1. The user attempts to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. The partner encodes the SAML response and the RelayState parameter and returns that information to the user’s browser. The partner provides a mechanism so that the browser can forward that information to Google’s ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to Google. The partner could also include JavaScript on the page that automatically submits the form to Google.
  7. 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.
  8. 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.

2. Introduction

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:


3  Enabling the Identity Provider functionality

Edit config.php, and enable the SAML 2.0 IdP:

'enable.saml20-idp' => true,
'enable.shib13-idp' => false,

4  Setting up a SSL signing certificate

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 []:gigih@unila.ac.id

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.

5 Authentication source

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).

6 Configuring the authentication source (For Test Only)

The 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 namedenable in modules/exampleauth/.

On unix, this can be done by running (from the simpleSAMLphp installation directory):

touch modules/exampleauth/enable

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 config/authsources.php.

In this example we will use the example-userpass, and hence that section is what matters and will be used.

$config = array(
    'example-userpass' => array(
        'student:studentpass' => array(
            'uid' => array('student'),
        'employee:employeepass' => array(
            'uid' => array('employee'),

This configuration creates two users – student and employee, with the passwords studentpass and employeepass. The username and password is stored in the array indexstudent:studentpass for the student-user. The attributes (only uid in this example) will be returned by the IdP when the user logs on.

7  Configuring metadata for an SAML 2.0 IdP

If you want to setup a SAML 2.0 IdP for Google Apps, you need to configure two metadata files: saml20-idp-hosted.php and saml20-sp-remote.php.

7.1 Configuring SAML 2.0 IdP Hosted metadata

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.

7.2 Configuring SAML 2.0 SP Remote metadata

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 john@foo.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  mahasiswa@students.unila.ac.id, the uid should be set to student.

You should modify the AssertionConsumerService to include your Google Apps domain name instead of g.feide.no.

For an explanation of the parameters, see the SimpleSAMLphp Identity Provider QuickStart.

8 Configure Google Apps for education

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


8.1 Add a user in Google Apps that is known to the IdP

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.

9 Test to login to Google Apps for education

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.

10 Security Considerations

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.

11 Support

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

 This is a authentication module for authenticating an user against a SQL database.
 : 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.
 : The username which should be used when connecting to the database server.
 : The password which should be used when connecting to the database server.
 : 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.
 Database layout used in examples:
 password TEXT NOT NULL,
 CREATE TABLE usergroups (
 groupname TEXT,
 UNIQUE(username, groupname)
 Example - simple setup, PostgreSQL server:
'sql-exampleorg' => array(
 '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(
 '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


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.


  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.