Using Centrify CIS & Active Directory to Secure Amazon's IAM In this post I describe a framework to leverage Centrify Identity Service to meet and exceed the Identity Management requiremen...
Using Centrify CIS & Active Directory to Secure Amazon's IAM In this post I describe a framework to leverage Centrify Identity Service to meet and exceed the Identity Management requirements for Amazon IAM while maintaining the corporate directory (AD) as the single-source of truth.
The example used in this blog post focuses on Active Directory, however, those who are familiar with Centrify know that the user sources can be or any other internal LDAP source, Google Directory, Federated Partner or even Social Identity providers.
The solution outlined below establishes a SAML federation agreement between Centrify Identity Service (CIS) acting as the Identity Provider (IdP) and Amazon AWS IAM acting as as the Service Provider (SP); Since CIS will be using Active Directory principals as an identity source, AD continues to be the single-source of truth for the enterprise and AD group memberships, AWS IAM Roles and CIS roles can be used to manage entitlements.
Enhanced Objectives
Eliminate duplicated administration efforts and align Amazon IAM users with corporate policy
Leverage AD Group membership (or CIS Roles) for Amazon IAM provisioning (add/moves/changes/deletions)
Leverage AD Group membership (or CIS Roles) and IAM Groups for Entitlement Management
Provide SSO to Amazon AWS with minimal federation infrastructure required
Enforce Advanced Policies: Require Multi-factor Authentication or Enforce Access from the Corporate Network
Limit access to IAM credentials to those with business need-to-know
Planning
Stakeholders
Identity and Access lead: Organizes and coordinates the effort.
Security SME: Outlines the security requirements based on policy or risk profile
Infrastructure SMEs: Execute the implementation of the tasks
Planning Discussions
Below are planning discussions that can be had around IAM:
What are the services being used in AWS? Will there be a process defined when new services are used?
Is there a list of the roles and the AWS policies that will be applied to those roles?
Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
Will contextual policy be needed? E.g. restrict access to corporate sites, geo-fencing or time-fencing?
What will be the attestation process for AWS users? (e.g. AD Group Management or CIS Roles/Reports)
Will Multi-factor authentication be required for IAM users? What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
Will approvals be required for IAM access? (Request/Approval)
Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration?
Will users be allowed to log in with their AWS password or just with SSO?
How will users be uniquely identified in AWS? (should shortname, email, UPN or another field be used?)
Our Example
The organization uses Amazon EC2 to hosts servers in the cloud
There are two types EC2 of users: Users with Full Access and ReadOnly Users.
Users with full access will be managed via AD Security group Membership (AWS-EC2-FullAccess)
Users with read-ony access will be requested on-demand (must be approved) via a CIS Role;
Another group (AWS-IAM-Managers) can manage IAM in AWS and will approve requests.
All users must provide step-up authentication via Token, Email, SMS or Phone to access AWS
The implementation will use the Centrify-provided SAML template
The Centrify-Provided PKI Certificate will be used for the SAML Assertion
Users will be identified in AWS with their Shortname.
Technical Requirements
Active Directory with security groups created and populated
Centrify Identity Service Tenant
A Member Server running the Centrify Cloud Connector with the AD Proxy capability enabled and connected
An Amazon AWS Account and a user with IAM rights to create an Identity Provider and Roles
Implementation
This process implies a partial configuration in CIS, followed by the configuration in AWS, finishing-up in CIS again.
Initial Configuration in Centrify Identity Service
Add and Configure the Amazon Web Services (AWS) Console: SAML+Provisioning
In Cloud Manager, navigate to Apps > Add Web App
In the Search Box, type AWS and press Enter, on the results, pick the "Amazon Web Services AWS Console SAML+Provisioning" template and click Add.
When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
In Application Settings: - Type your AWS Account ID (if you don't know it, go to "My Account" in AWS) - Click the "Download SAML provider metadata document" link, this will save the XML file in your downloads folder
In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
Skip User Access and Policy (we'll revisit)
In Account Mapping , use the "Use Account Mapping Script" option and type the following:
LoginUser.Username = LoginUser.Shortname
This option will send the user's shortname as the identifier. If there are duplicates, you can switch to mail or UPN.
Press Save, you'll have to return here for adjustments.
Configuration in AWS
Create the Centrify SAML IDP
Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
On the left pane, click Identity Providers and press the Create Provider button on the right
Select SAML in provider type
In provider name type a descriptive name like "Centrify" or "CentrifySAML"
In Metadata Document, browse to the downloads location where the XML file from step 4 above was saved, press Next Step and press Create.
Configure the AWS IAM Roles for the Centrify SAML IdP
On the Amazon AWS IAM Dashboard, Click Roles > Create New Role The names of the roles about to be created must match the role names in Centrify Identity Service.
Example: EC2 Administrators - this role grants the ability to manage all aspects of EC2 instances, therefore a policy that matches that entitlement has to be tied to the role. Name: AmazonEC2Admins Role Type: Role for Identity Provider Access > Grant Single Sign-On (WebSSO) access to SAML providers [Select] Establish Trust: SAML Provider > Select Centrify > Press Next Step Verify RoleTrust: Press Next Step Attach Policy: type "AmazonEC2FullAccess" and Check the box This corresponds to the administrative role for EC2 instances Review: Press Create Role
Repeat the process for the rest of the roles. Make Sure that you are writing down the names of the Roles.
Finishing the Configuration in Centrify Identity Service
Create and Populate the Centrify Identity Service Roles
In Cloud Manager, navigate to Roles > Add New Role
Name: AmazonEC2Admins (must match the name of the corresponding role in AWS)
Members: Populate based on your requirements. For AmazonEC2Admins I'm leveraging AD membership
Press Save. Repeat with any other roles created in AWS
Complete the User Access Section of the AWS Role-Based SSO App
In Cloud Manager, navigate to Apps > Click your AWS SAML App
Go to User Access and check the box on the roles you've created.
Press Save, you are ready to verify.
Verification
At this point you can verify access. If using Active Directory, simply add a user to any of the AD Security groups that grant access and the user will get the App automatically. Upon clicking on it they'll be able pick the role (or roles, in case of multiple entitlements) and simply press sign-in.
They should only be entitled to the activities allowed by the policies associated with the role. For example, in the case above the user will only be able to manage EC2 instances and details, no more than that.
I switched the user to a different role (EC2ReadOnly), and we inspect the login menu in AWS, notice that the user type is "Federated User" with the role tied to it.
The benefit of this approach is that all the user lifecycle, entitlements and corporate policies (like password policy, etc) are enforced in the on-premises Active Directory. This accomplishes the goal of simplified administration and de-duplicates efforts.
Adjustments
Adding Multifactor Authentication , Limiting Access from the Corporate Network and Workflow and Approvals
MFA is built-in to Centrify Identity Service. All you need to do is check the box, and provided there's an authentication profile that will support the step-up methods you will be set. These include and are not limited to: Centrify's Mobile Authenticator, Phone call, SMS, Security Question, Email or OATH Based OTP (Duo, Google Authenticator, Amazon Virtual OTP)
To limit access based on the corporate IP range, all you need to do is populate the NAT addresses for the organization and check the appropriate box.
To establish a workflow and approvals scheme, a role needs to be designated as the approver, see the video playlist below or the one included in part two to view the particulars.
Provisioning of IAM Users
There are instances in which it is desirable to have a provisioned user inside AWS IAM. What needs to be reconciled is if users will know their IAM passwords, in that case they can go directly to the sign-in page and bypass the controls outlined above. We can extend the SAML template to provide provisioning capabilities as well.
Enhancements of CIS 2016.2
Amazon AWS provides an virtual MFA capability that leverages OATH. As of February 2016, Centrify allows you to use any OATH based OTP mechanisms, this means that you can leverage those mechanisms as well.
