a good thing!
Security in the public cloud presents a unique set of challenges for enterprises today. It’s imperative that users have the correct access to do what they need to do without compromising security.
This eBook outlines how your organization can leverage security assertion markup language (SAML) and OpenID® Connect federation capabilities to streamline user access to Amazon Web Services™ (AWS) resources while providing the same level of security that your on-premises environments have. We’ll also share examples of incorporating the Ping Identity® solution using PingFederate® to provide single sign-on (SSO) into AWS from directory servers such as Microsoft® Active Directory. This approach gives you the ability to re-use existing internal identity management processes, such as onboarding and offboarding, as well as policies like password length, age and complexity. With this approach, you’ll also be able to provide a seamless, federated SSO experience that will get your admins, developers and users authenticated, signed on and doing what they do best, quickly. This is sure to bump you up to superhero status within your organization!
Amazon Web Services provides a rich set of identity and access management (IAM) capabilities, including the ability to create and manage users and groups and apply specific access controls based on the user’s role or group membership. Individual security credentials can be set per user, and the architecture provides security by default rather than as an afterthought. Additionally, IAM in AWS provides centralized user access control through fine-grained permissions for both APIs and the AWS console.
Controlling users’ access to APIs and the AWS console is an ongoing consideration for today’s enterprise organizations—and not just from the administrator’s perspective. The developers that are writing applications within AWS also need seamless access to APIs, and they don’t have the time or patience to remember multiple, always-rotating AWS passwords.
Identity and access management within AWS provides the answer to two critical questions:
1. WHO CAN SIGN ON? Authentication is used to confirm the identity of a given user. AWS users can be authenticated internally or they can be federated from an external identity provider which handles authentication. The existence of a user account defines who can authenticate into the system.
2. WHAT CAN THEY DO? Authorization and access control policies provide the answer to what users can do after they are authenticated.
More Cloud Deployments Means More Access
MORE CLOUD DEPLOYMENTS = MORE ADMINS AND MORE USERS!
With increased deployments in the cloud comes the need for administrators and users with varying access rights. Managing these users and groups in multiple places quickly becomes tedious for administrators, leading to a loss of productivity as well as risky security practices.
ENTER FEDERATION TECHNOLOGY
With a federated architecture, you can:
Identity Federation in AWS: Four Scenarios
AWS as a SAML Service Provider (SP):
Organizations can leverage a third-party IAM system for a turnkey solution that manages identities and delivers SSO for AWS. The IAM system authenticates users and they are federated into the AWS console with the correct permissions and entitlements.
AWS as an OpenID Connect Relying Party (RP):
Organizations can also use a third-party OpenID Connect authorization server (AS) to access AWS APIs. The AS authenticates users and they are given an ID token that can be traded for AWS credentials that are used to call AWS APIs.
Federated Identity Provider Inside EC2:
Identity provider (IdP) and authentication functionality can be provided through a federation server or identity bridge running in EC2. Users are authenticated and given a SAML assertion or token for transparent, standards-based SSO.
Federated Service Provider Inside EC2:
Service provider functionality can be enabled through a federation server deployed in EC2 that can consume SAML or other SSO tokens and provide a local token or session that is used to access applications.
What is a Cloud-Based Federation Identity Provider?
How We Got Here: The Good Ol' Days
Prior to native federation support in AWS, organizations typically had to write custom code to authenticate users and obtain keys. These proprietary, one-off solutions required storing multiple user keys, often insecurely, and provided limited functionality through the AWS APIs and command line interfaces.
Federate to AWS for Security and Productivity
SAML federation in AWS allows organizations to leverage a commercial federation server as an identity bridge, providing secure single sign-on into the AWS console without storing user keys and without additional passwords or sign-ons.
The IdP will typically support multiple methods of authentication, allowing users to leverage Kerberos if they are on the corporate domain, and providing other types of strong authentication to users off of the network, such as X.509 certificates or one-time passwords.
TOP THREE RECOMMENDATIONS FOR INCORPORATING FEDERATION WITH AWS:
Identity Federation: Fulfilling the Contract
The IdP fulfills the contract by either dynamically retrieving the appropriate attributes from a data source or by using hard-coded values during SSO. The IdP inserts these attributes into the contract, which is then delivered to AWS. AWS wants to know two things, the role entitlement and session name attributes. The role entitlement attribute describes who is authorized to issue SAML assertions to a user and what AWS role they should be given (concatenated into a single attribute). The role session name tells AWS which user has assumed the described role (typically the username). In the AWS console, the IdP must be defined to establish trust with AWS. The SAML assertion then references the IdP’s Amazon resource name (ARN). Additionally, the role that the user should assume is also defined along with specific permissions for the role. The role is then included in the assertion so that the IdP can dynamically define which privileges the user should have for a given session. These privileges, for example, may be different depending on how the user was authenticated or from where the user signed on.
Leverage OpenID Connect for AWS APIs
Amazon recently announced support for identity federation using OpenID Connect. This functionality can be used to easily access AWS resources from non-web clients, although the mechanism can be used for web applications as well.
This new feature allows developers to leverage an OpenID Connect authorization server like PingFederate to provide SSO capabilities similar to those available from cloud identity providers such as Google and Facebook. For service providers who publish apps that rely on AWS APIs, this enables simple, secure access using a standards-based framework that supports both web and mobile clients.
EC2 Provides a Supported Platform for Federating Your Identities
Regardless of whether your users are employees, contractors, partners or affiliates, a federation server deployed in EC2 allows you to authenticate users and provide assertions or tokens for AWS, your own applications or third-party SaaS providers.
EC2 Can Host a Federation Server to Accept Inbound Assertions and Tokens
If your users are being authenticated by their own IdP, EC2 also provides a supported platform for a federation server to consume identity assertions and tokens and then provide a local session or token that can be used by your applications. Deploying a federation server in EC2 offers instant scalability and availability for your environment.
Superhero Status: AWS for Enterprise Identity
Leveraging AWS for identity federation allows scalable, highly-available SSO and token services for the AWS console and APIs, as well as for your own applications. By leveraging other AWS components such as S3, RDS, Route 53 and ELBs, you can provide a scalable, highly-available IAM infrastructure that provides a true SSO solution while leveraging your current identities, directories and policies.