Implementing Google SSO

Here at Reckonsys we recently had to build a tool where one of the requirements was a Google SSO Login.

What is Single Sign-On?

Single sign-on (SSO) is a property of access control of multiple related, yet independent, software systems. With this property, a user logs in with a single ID and password to gain access to a connected system or accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers. A simple version of single sign-on can be achieved over IP networks using cookies but only if the sites share a common DNS parent domain. Read more on this at Wikipedia

SAML:

SAML (Security Assertion Markup Language) is an XML-based standard for web browser single sign-on (SSO) that eliminates application-specific passwords. SAML uses single-use, expiring, digital “tokens” to exchange authentication and authorization data between an identity provider and cloud application service provider that have an established trust relationship.

Configuring SSO:

We used SAML 2.0 for implementing SSO and used djangosaml2 library.

1. We need to create an SAML app in Google Admin of organization account. Instructions are provided here for the steps to be performed to create the app.
2. Things to note while creating the Google SAML app.

• The ACL url acts as a callback post authentication from Google.
• ACS url needs to be configured using SSL(https). We used LetsEncrypt to generate SSL certificates
• Attribute Mapping allows to add attributes to the app which will return us those values(for eg. First Name, Last Name, Email, etc.)

1. Once the SAML app is created you have to set the service on and set it operational.
2. In the process of creating SAML app, Google will provide an Enitity Id, IDP Certificate and IDP Metadata xml file. We will need to provide the metadata file.
3. Follow the directions provided in djangosaml2 to setup the library.
4. Add a PySaml2 config similar to the one provided below.
   ``` SAML_CONFIG = { # full path to the xmlsec1 binary programm 'xmlsec_binary': '/usr/bin/xmlsec1', # your entity id, usually your subdomain plus the url to the metadata view # 'entityid': 'https://accounts.google.com/o/saml2?idpid=GT30r3', 'entityid': 'https://accounts.google.com/o/saml2/idp?idpid=GT30r3' , 'service': { # we are just a lonely SP 'sp': { 'name': 'Federated Django sample SP', 'name_id_format': saml.NAMEID_FORMAT_PERSISTENT, 'endpoints': { # url and binding to the assetion consumer service view # do not change the binding or service name 'assertion_consumer_service': [ ('https://xyz.com/sso/google/acs', saml2.BINDING_HTTP_POST), ], # url and binding to the single logout service view # do not change the binding or service name 'single_logout_service': [ ('http://xyz.com/saml2/ls/', saml2.BINDING_HTTP_REDIRECT), ('http://xyz.com/saml2/ls/post', saml2.BINDING_HTTP_POST), ], }, # attributes that this project need to identify a user 'required_attributes': ['uid', 'surname', 'givenName', 'mail'], }, }, # where the remote metadata is stored 'metadata': { 'local': [os.path.join( BASE_DIR, 'settings/saml/google_idp.xml')] }, # set to 1 to output debugging information 'debug': 0, 'organization': { 'name': [('XYZ Pvt Ltd.', 'en'), ], 'display_name': [('XYZ', 'en'), ], 'url': [('https://www.xyz.com', 'en'), ], }, 'valid_for': 24, # how long is our metadata valid } ```

Once the SAML configuration is done the authentication should be working fine. It will return a callback to ACS url. The response will be based on authentication result provided by Google. The ACS url callback data contains the attributes we added in SAML app in step 2. We can use that data to update in the database and any further action we want to perform.

Finally, we can then perform a session login using django’s inbuilt login method or any other authentication method.