Single sign-on (SSO) technologies allow organizations to invest in SaaS applications while retaining central control of passwords, access to control lists, and multi-factor authentication schemas. Just as importantly, SSO allows users to access all of their applications with a single set of credentials.
Why Use SSO With BetterWorks?
There are many compelling reasons to use single sign-on with BetterWorks and the other cloud applications your business uses:
- Improved employee efficiency: Do you have trouble remembering many different sets of credentials? Do complex password policies frustrate you? Many users experience these frustrations. By implementing SSO, users are able to access all of their corporate resources with a single set of credentials.
- Enhanced password security: When people have to remember many passwords, they tend to either write them down or repeat the same passwords for all of their applications. Using the same password to access many different sites means the password is only secure as the least secure site in the group.
- Reduced risk: With SSO implementations, the SaaS application doesn’t handle authentication tasks, like password resets, and passwords are not stored within the SaaS application. Because these are managed centrally, vectors for hacking and phishing attacks are minimized. All user authentication information is passed between servers using 256-bit SSL encryption.
- Centralized control: Using SSO solutions, corporations can centrally manage access to all of their corporate applications, control password complexity, implement multi-factor authentication schemas, leverage on the fly provisioning, and keep user identity information in sync from a central user store.
BetterWorks and Federated SSO
All SSO implementations require the following:
- An Identity Provider (IDP): an entity that manages user authentication
- A Service Provider (SP): the application or resource a user wants to log in to
- A secure connection and communication protocol between the IDP and the SP
Two of the most common standardized communication protocols are the Security Assertion Markup Language (SAML) and OAuth. BetterWorks supports single sign-on using Google’s implementation of OAuth, the SAML 2.0 federation standard.
There are three ways to implement SSO:
- Use a third-party SSO provider as an IDP, such as Ping Identity, Okta, or OneLogin. The benefits of this approach include rapid deployment and more robust SSO and provisioning capabilities with web applications, including BetterWorks. Most third-party SSO solutions integrate with enterprise directories such as Active Directory (AD).
- Do it in-house. You can implement an identity provider within the enterprise, using an internal LDAP directory (which could be Active Directory) and SAML federation software. Completing the integration using native Windows, Unix or Linux tools requires in-house integration work, expertise and support.
- Use Google Apps with OAuth based SSO integrations.
How SAML-Based SSO Works with BetterWorks
BetterWorks communicates with your organization’s IDP to get the information it needs to authenticate users and allow them access into BetterWorks, whether they’re connecting from a web browser or using mobile apps.
There are two ways that employees might connect with BetterWorks when using SSO:
- Initiating the session from the identity provider (IDP initiated), or
- From a BetterWorks login screen (SP initiated)
Below is an example of an SP initiated login flow:
Initiating SSO from the BetterWorks Login Screen: SAML (SP Initiated)
This is an example of a SP initiated login flow.
- The user goes to the BetterWorks login page and enters their email address.
- If they have already authenticated with the IDP, the IDP exchanges SAML assertions with BetterWorks to authenticate the user. If the user entered the correct password, they can log in to their BetterWorks account.
- If the user hasn't yet authenticated with the IDP, they're redirected to the IDP login page to enter their credentials there. After they authenticate, they are redirected to BetterWorks.
Initiating SSO to BetterWorks from the Identity Provider - SAML (IDP initiated)
One example of an IDP-initiated SSO begins in a portal hosted by the IDP. The portal provides employees access to all authorized applications.
The user authenticates with the IDP to reach the application portal, then simply clicks a link or icon to access an application without needing to authenticate again.
The IDP exchanges SAML assertions with BetterWorks to authenticate the user.
Using OAuth-Based SSO with BetterWorks
This is another example of a SP Initiated Login flow.
- The admin enables the Google Apps domain in the BetterWorks backend.
- The user goes to the BetterWorks login page and enters their corporate email address.
- If the user has already authenticated with Google Apps, then BetterWorks will authenticate the user and open their account.
- If they haven't yet authenticated with Google Apps, they will be redirected to their Google login page to enter a password.
- Once they are authenticated, they are redirected to the BetterWorks application.
BetterWorks Mobile Apps with SSO
The BetterWorks mobile app has an embedded browser.
For an SSO enabled BetterWorks account, users will be able to perform SP initiated login flows. Today, the BetterWorks mobile app is not compatible with IDP initiated login flows.
Also, in configurations where the IDP is not web facing, it may be necessary to either move the IDP login service to the DMZ, or ensure mobile devices are within the Virtual Private Network (VPN) so that users are able to reach the IDP's login screen.
Please consult your IDP's instructions for details on how to make the Login flow compatible with mobile devices.
SSO Implementation Instructions
For instructions on implementing SSO, in your BetterWorks environment, read the SSO implementation instructions.