Identity Federation and SSO for SaaS on AWS

Editor’s note: For the latest information, visit the SaaS on AWS website.

By Matt Yanchyshyn, Senior Manager of Partner Solutions Architecture at AWS

AWS Security If you are building a Software as a Service (SaaS) solution on AWS it is important to track who is using your application. Most SaaS solutions also require an authentication layer and secured data that is linked to identity so you can build a personalized user experience, allow users to store documents and settings, and implement access controls. Nobody likes remembering another password; reducing login friction is very important for keeping user retention high. Administrators do not like passwords either, since there is operational burden involved in storing them security in addition to the resources needed to process logins.

Perhaps most importantly, if your application is not connected to enterprise identity stores such as LDAP or Microsoft Active Directory revoking access when an employee leaves or changes roles can be complicated. To address this, single sign-on (SSO) has been widely adopted as it allows people to transparently login to your SaaS applications using the authentication granted by another source. This means fewer passwords to remember and more flexibility for your users, plus when implemented correctly you can get useful analytics and increased security for your applications. In this blog post we explore some of the technologies and concepts behind SSO and linking third-party user identity to your applications (identity federation), plus explore some of AWS products and partner solutions that can help with implementation.

SSO should be a simple experience for the end-user, but it relies on a complex chain of events on the backend. “Identity, authorization and authentication” is a commonly used description of the steps needed in any standard SSO process. Identity is who you are, authentication proves that you are that person or thing, and authorization decides what you are allowed to do. Most SaaS solutions also implement a fourth step: audit. This allows you to link established identities to activities, from logins to application-specific actions.

Authorization

The authorization piece of identity federation follows a similar pattern to AWS Identity and Access Management (IAM) roles for Amazon EC2: you authenticate with Amazon to access AWS APIs or the management console, and then launch an EC2 instance with an IAM role. The policy associated with that IAM role determines what applications running on that Amazon EC2 instance can do. Identity federation is pretty much the same, in that authentication happens outside of the application, then a secure set of processes and policy determine what users can see and do once they login successfully and access your application.

We take this approach for our own AWS Management Console, allowing you to leverage your own federated identity solution to grant role-based access to your users:

This is where identity protocols come in. They allow you to associate identity stored elsewhere with your application and determine how that identity should be mapped to application-level permissions.

Identity Protocols

In the case of SSO to the AWS Management Console, you use AWS STS to generate temporary credentials that expire after a given amount of time. IAM policies are used to determine what AWS services and features a user inheriting those credentials can access. In your own application, you may have a custom token or credential generator. Before you hand over access keys and assign an access policy you will need an assertion from your trusted identity provider that a valid user is requesting the access keys without necessarily knowing that user’s password. SAML 2.0 and OpenID Connect are two of the more popular identity protocols that handle this.

Finalized in March 2005, Security Assertion Markup Language (SAML) version 2.0 is a sign-in protocol that uses XML to exchange information. In the body of the XML token, there are digital signatures that establish trust between the identity provider and the application. You can also optionally encrypt the data and enforce security policies such as mandatory two-factor authentication. I like to joke that SAML 2.0 is your grandma’s identity protocol. It’s tried, trusted and true (and easily the most popular), but is starting to show its age.

OpenID Connect 1.0 is simple identity layer built on top of the OAuth 2.0 protocol. Like SAML 2.0, it allows third parties to confirm your identity without knowing your password. Unlike SAML, its token format is much more compact and is JSON-based. Some people confuse it with both OpenID 2.0, its older, XML-based cousin, and OAuth 2.0. OAuth 2.0 on its own is not used for authorization, authentication or federation; it is only for delegation. OpenID Connect 1.0 extends the OAuth 2.0 protocol, allowing for things like encryption and identity information included in the payload. Unlike SAML 2.0, there is no signed identity information in the token so an additional round trip is required to validate the token. Despite this, the OpenID Connect flexible token and protocol design has led many developers to adopt it for identity federation/SSO. Examples include Google+ Sign-in, Microsoft and Salesforce. Other popular web identity federation (WIF) systems such as Facebook Login and Login With Amazon also use OAuth 2.0, but use their own OpenID Connect 1.0-like identity layer.

Choosing an Identity Store

Deciding what identity store to use is your first and arguably most important decision. Trust is incredibly important for SaaS providers, especially those hosting sensitive information, so you can potentially reduce risk and increase security by outsourcing your identity store to a secure, third party that your users already trust. These could be popular web services such as Amazon.com, Facebook or Twitter. Enterprises typically have their own trusted identity stores that you can leverage indirectly for your applications. These include LDAP, Microsoft Active Directory/ADFS, Shibboleth, CA SiteMinder, Oracle Identity Manager, Novell SecureLogin and others.

The AWS Directory Service is another option. Based on SAMBA 4, it allows you to provision a directory of users, add group memberships, join machines to domain, implement Kerberos SSO, and apply Group Policy. AWS Directory Service can also extend an existing Active Directory (AD) into the cloud and is integrated with IAM. This way can provide SSO to the AWS Management Console for users associated with the directory directly or via your AD servers.

Brokering Multiple Identity Stores

The good news is that you do not have to choose just one identity store: there are many popular identity brokering solutions that can offer multiple login choices to your users. These solutions also allow you to audit access activities, giving you additional visibility across potentially multiple identity stores into who is using your application and how. Importantly, several of these solutions support multi-factor authentication, where a user has to input a code received by SMS or generated on a personal hardware device to login, either natively or when combined with a complementary AWS partner solution. Ping, Okta, SecureAuth and Auth0 are just a few of the AWS partners who provide identity management solutions for SSO and federation that can span multiple identity providers. Read more about the available options here.

Amazon Cognito is a service that makes it easy to save user data, such as app preferences or application state, in AWS without writing any backend code or managing any infrastructure. It can also act as an identity broker, essentially providing a superset of the functionality provided by a WIF. Amazon Cognito supports several popular WIFs, including Login With Amazon, Google Sign-In, Facebook Logic, Log in with Twitter and any OpenID Connect compatible IdP. It also has a built-in credentials provider and because it’s integrated with the AWS SDK it’s easy to use with applications built for AWS.

Putting it All Together

Users increasingly want to use a single set of credentials across multiple SaaS applications. We have seen this demand ourselves in the demand for SSO/federated access to the AWS Management Console. Administrators also want to centralize account, authentication and authorization management in order to ease the operational overhead associated with user and policy management as well as to gain valuable insight into usage patterns. Security teams want to be able to revoke access easily when employees leave companies and change roles, plus want to be able to enforce security policies like two-factor authentication. All of this can be accomplished using the right combination of identity providers, identity protocols, brokering solutions, temporary tokens and role-based access.

At AWS, we always start with customer requirements and then work backwards when we are building new products and features. When you are deciding how to build the identity, authentication, authorization and audit components of your SaaS application, it’s a good idea to take the same approach. Do your customers already have an enterprise identity store that they would prefer to leverage for SSO? Does that identity store support SAML 2.0 or OpenID Connect 1.0? Do you serve users with multiple identities and therefore, would an identity brokering service be a good idea? Asking yourself these questions and others related to the information above will save you lots of time down the road and result in a better user experience.

Conclusion

Let go: outsource identity management unless you really need it, reducing undifferentiated heavy lifting so you can focus on your core business
Work backwards from your customer: choose identity stores and protocols that best suit your customer base
Be flexible: use identity brokers to allow you to support multiple identity protocols and identity providers
Less is more: only ask for the user data you need specifically for your application. Leave the rest with the identity provider, earning customer trust and decreasing liability/risk
Embrace the future: don’t lock yourself into aging protocols like SAML 2.0

Learn more about the AWS SaaS Partner Program >>

AWS Partner Network (APN) Blog