GSuite Biometric Integration with VeridiumID for Single Sign-On

This is the first in a regular series of technically-focused articles from our product team. This article focuses on the configuration steps required to use the VeridiumID platform to add biometric authentication for single sign-on with GSuite. In this instance we do not provision accounts within GSuite, instead relying on Active Directory to provide the required account attribute (email address) for login.

The scope of this integration covers sign into GSuite services using a web browser, or applications capable of displaying a WebUI, for single sign-on using biometrics. It does not include applications like direct IMAP integration, which are not capable of displaying a WebUI, and will therefore still require a password to log into.

Prerequisites

• A functioning VeridiumID installation including:
  • Active Directory Service with VeridiumAD, including an enrolled device for every user that requires GSuite access.
  • Shibboleth has been installed and configured to retrieve and map attributes from Active Directory.
• Manually editing files on Linux using SSH.
• Every user account in Active Directory that requires GSuite access has the “mail” attribute populated, matching the GSuite email address. It is possible with minimal configuration changes to map another attribute, but this article uses the “mail” attribute as an example.

Functioning GSuite implementation

• User accounts already created at admin.google.com with the email address matching AD (as described above).
• User accounts should have the necessary services enabled. For example, we can facilitate authentication to Gmail, but if the user has not been provided access to this service, then an error is displayed in the browser.

• This is a GLOBAL setting for all WebUI logons. Once this setting is enabled, it will impact all users. Therefore, for evaluation/PoC purposes, I suggested you do this in a sandbox instance (provided by Google). This is a Google limitation.

VeridiumID Configuration Steps

Throughout this guide, you will be asked to edit a number of configuration files. Samples from functional implementations are available here for comparison.

Please modify the following files as outlined below. This guide assumes the shibboleth installation directory is /opt/shibboleth-idp.

• Create google.xml in the /opt/shibboleth-idp/metadata/ directory with the following content. Replace ***YOURGOOGLEDOMAIN*** accordingly.

<EntityDescriptor entityID="google.com/a/***YOURGOOGLEDOMAIN*** xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>
<AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://www.google.com/a/***YOURGOOGLEDOMAIN***/acs" />
</SPSSODescriptor>
</EntityDescriptor>

• Edit metadata-providers.xml and edit the *default* Metadata-ProviderID to point to the Google.xml file created above. Please note, you can add multiple metadata providers by following the guidance here.

<MetadataProvider id="LocalMetadata" xsi:type="FilesystemMetadataProvider"
xmlns="urn:mace:shibboleth:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd"
failFastInitialization="true"
requireValidMetadata="false"
metadataFile="%{idp.home}/metadata/google.xml"/>

• Edit the relying-party.xml file and append an entry for GSuite.

<bean parent="RelyingPartyByName" c:relyingPartyIds="google.com/a/***YOURGOOGLEDOMAIN***>
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO" p:encryptAssertions="false" p:signResponses="true" p:signAssertions="false" p:encryptNameIDs="false" p:includeAttributeStatement="false" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
</list>
</property>
</bean>
</util:list>

• Edit the attribute-filter.xml and append an entry for GSuite.

<AttributeFilterPolicy id="google.com/a/***YOURGOOGLEDOMAIN***">
<PolicyRequirementRule xsi:type="OR">
<Rule xsi:type="Requester" value="google.com/a/***YOURGOOGLEDOMAIN***" />
<Rule xsi:type="Requester" value="google.com/a/google.com" />
</PolicyRequirementRule>
<AttributeRule attributeID="mail">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>
<AttributeRule attributeID="userPrincipalName">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>
</AttributeFilterPolicy>

• Edit the saml-nameid.xml file and ensure that the SAML1 and 2 nameID configurations look like this:

<!-- SAML 2 NameID Generation -->
<util:list id="shibboleth.SAML2NameIDGenerators">
<ref bean="shibboleth.SAML2TransientGenerator" />
<!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
<!-- <ref bean="shibboleth.SAML2PersistentGenerator" /> -->
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
p:attributeSourceIds="#{ {'mail'} }" />
</util:list>
<!-- SAML 1 NameIdentifier Generation -->
<util:list id="shibboleth.SAML1NameIdentifierGenerators">
<ref bean="shibboleth.SAML1TransientGenerator" />
<bean parent="shibboleth.SAML1AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
p:attributeSourceIds="#{ {'mail'} }" />
</util:list>

• Restart Tomcat using the command ‘systemctl restart tomcat.service’. Remember, if the server hosts the other VeridiumID components, it may take 50 seconds or so before the server is up and running and ready to accept requests.

GSuite Configuration Changes

Public Reference: https://support.google.com/a/answer/60224?hl=en

• Login to admin.google.com using a GSuite administrator account
• Select ‘Security’

• Select ‘Set up single sign-on (SSO)’

• Configure the following fields
  • Sign-in page URL – This is the address for the VeridiumID server that has Shibboleth installed (or a standalone Shibboleth instance, configured with a separate VeridiumID server). If this is the OVA, Shibboleth listens on port 8443; however, this is configurable, so adapt this for your installation. The path defaults to the one shown in the image below.
  • Sign-out page URL – This is the same FQDN as above but with a slightly different path as you can see from the image below. https://**veridiumid.domain.com/idp/profile/Logout.
  • Verification Certificate – Upload from opt/shibboleth-idp/credentials/idp-signing.crt
  • Use a domain specific issuer – This is optional. If you do NOT tick this box, Google will identify itself to Shibboleth as ‘Google.com’. If you use a domain specific issuer, it will identify itself as google.com/a/your_domain.com. You may prefer to enable this setting to ensure requests redirected from other GSuite instances are rejected sooner in the verification process. For my example (and the configuration above), I have opted to enable this setting as I feel it is the most likely real-world requirement.

• Click ‘Save’

Testing the Configuration

I recommend using a private browsing session when testing the integration to prevent caching. This can be a problem if you need to make more than one attempt to get it right! These steps assume that you have already enrolled and the user account matches the prerequisites at the top of this article.

• From a web browser, go to a GSuite URL. I used gmail.com.
• Type in the email address of the user. In my example, I have my Android device enrolled against rpenny and rpenny has the GSuite email address mapped correctly to the AD object as shown above.
• You are redirected to a page displaying a QR code.
• Scan QR code and perform biometric authentication.
• You are redirected back to Gmail and signed in.

Troubleshooting

The Shibboleth logging engine is very, very good will guide you easily through any errors you might encounter. To enable ‘debug’ logs, please edit /opt/shibboleth-idp/conf/logback.xml as shown below, then restart tomcat.

Conclusion

The advantages of adding multi factor biometric authentication to enterprise accounts are many. By incorporating it into GSuite for single sign-on we are able to provide end users with a seamless experience across platforms and simplify their security and access needs. The VeridiumID platform offers many integrations, including Microsoft Active Directory, Citrix StoreFront, NetScaler, and ShareFile, and many more. We are always in the process of supporting new services and systems as part of this project, as well as improving interoperability.