A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 3

Background
This is the third article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to secure the Amazon Root account.
In this article we'll discuss how Centrify can secure Amazon Identity and Access Management by leveraging Active Directory or any other supported Identity Source. 

About Amazon AWS Identity and Access Management (IAM)
For those who aren't familiar with Amazon IAM, it provides capabilities that allow organizations to centrally manage Users, Roles, Rights and Policies efficiently for all services (compute, storage, database, application) provided by the platform. 

Another Identity Silo
Each time a new infrastructure or application is introduced, it has the potential to create another identity silo, Amazon AWS is not the exception.  Large organizations often find themselves duplicating effort by managing their own enterprise directory (like AD) and also having to manage the directory out in the IaaS or SaaS provider.
Many of our customers and prospects due to timing of adoption or while developing cognitive knowledge, find themselves manually managing Amazon IAM.  The typical tasks include user creation, credential/password/key management, password resets, group/entitlement management and attestation. The basic IAM best practices are outlined when you log in to the IAM dashboard:



Once we adopt this "dual-management" we are promoting IT fragmentation, the potential consequences are complexity, limited productivity and possible security expose.  Finally, depending on the data classification or risk profile of the assets in AWS, this identity silo is subject to the corporate security policy (password policies, user attestation reporting, least access management, etc.)

In the past few years, Amazon has recognized this challenge and provides vast extensibility to IAM, via APIs and using standards like SAML and OpenID Connect. 

This article provides a practical example that not only meets but exceeds the best practices around Amazon AIM, eliminates dual-administration and aligns administration with internal policies.

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 AIM 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:

1. What are the services being used in AWS? Will there be a process defined when new services are used?
2. Are there any AWS IAM Groups that provide separation of duties (e.g. EC2 Management vs. IAM Management)?
3. Will Active Directory Groups be mapped to AWS IAM Groups? or Will Centrify Roles be used?
4. Will contextual policy be needed?  E.g. restrict access to corporate sites, geo-fencing or time-fencing?
5. What will be the attestation process for AWS users?  (e.g. AD Group Management or CIS Roles/Reports)
6. Will Multi-factor authentication be required for IAM users?  What factors (Centrify MFA, Amazon Virtual Token (OATH), SMS, Phonefactor or Email?
7. Will approvals be required for IAM access?  (Request/Approval)
8. Will just-in-time provisioning be used (E.g. AD group addition triggers an AWS IAM provisioning)?
9. Will SAML, OpenID Connect or Amazon's API be used to establish AWS integration? 
10. Will users be allowed to log in with their AWS password or just with SSO?
11. 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

1. In Cloud Manager, navigate to Apps > Add Web App
2. 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.
   
3. When ask to confirm if you want to add the app, click Yes. This will open the app template for configuration.
4. 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
   
5. In Description, give the application a descriptive name (e.g. AWS Role-Based SSO)
6. Skip User Access and Policy (we'll revisit)
7. 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.
8. Press Save, you'll have to return here for adjustments.

Configuration in AWS
Create the Centrify SAML IDP

1. Sign-in to AWS and navigate to Security and Identity > Identity and Access Management
2. On the left pane, click Identity Providers and press the Create Provider button on the right
3. Select SAML in provider type
4. In provider name type a descriptive name like "Centrify" or "CentrifySAML"
5. 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

1. 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.
2. 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
3. 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

1. In Cloud Manager, navigate to Roles > Add New Role
2. Name: AmazonEC2Admins  (must match the name of the corresponding role in AWS)
3. Members: Populate based on your requirements.  For AmazonEC2Admins I'm leveraging AD membership
   
4. Press Save.
   Repeat with any other roles created in AWS

Complete the User Access Section of the AWS Role-Based SSO App

1. In Cloud Manager, navigate to Apps > Click your AWS SAML App
2. Go to User Access and check the box on the roles you've created.
   
3. 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.


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.

Video Playlist

Business Cases - Web-Mobile SSO Planning Session II: Apps

Planning for Applications

When we plan for Applications (Web or Mobile), we need to think about different strategies.  These types of questions arise:

• How will the application be published?  
  Centrify provides the user portal, however, depending on your environment, you may have an intranet or content management platform that is used as a hub for applications.
  
• What is the policy to access these applications?
  Apps can have different assurance requirements.  Maybe certain portions of the HR app are for intranet-only access with step-up (or two-factor) authentication.  Maybe your Netsuite-based ERP should only be available from inside of the United States.
  
• Who should be entitled to access each app?
  Your security team may want to grant access based role or job function.  Centrify User Suite uses AD or Cloud Directory principals for app visibility.
  
• What are the authentication capabilities of the app?
  Modern (especially cloud-based apps) provide federation technologies (like SAML, etc) but legacy apps don't have those capabilities or aren't available in the current version.  Also (and unfortunately) not all apps may be looking at the corporate directory (e.g. AD) as the identity repository (which can enable Kerberos or NTLM).  CUS offers the flexibility of password-vaulting and replaying.
  
• How is the application provisioning model?
  This topic impacts the bottom-line of the business because the timely deprovisioning of cloud apps can impact the billing depending on how the application provider is metering the usage of the application.  In addition, some apps need to have entitlements provisioned as well for the purposes of role-based access.
  
• What is the strategy for on-premise apps?
  Are these apps accessible via an existing VPN infrastructure (e.g. CheckPoint, Cisco, Microsoft's DirectAccess or others) or will you make use of the Centrify App Gateway (VPN-less access)?
  

These are high-level categories, there are advanced topics like timeouts, attribute-mapping, provisioning of certificates for federation trust, etc; but we will cover each scenario individually.

We will start by publishing these Web applications:

• On-premises SharePoint (as a shortcut)
• On-premises Apache or Java-based apps (leveraging NTLM, Kerberos & ADFS-less WS-Fed apps)
• Google Apps
• Salesforce
• Office365.

Later we'll move on to Mobile apps on the Google Play and Apple App Store.

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:

• It's a cloud-based Identity Provider
• It provides access and SSO to on premise and cloud apps
• Provides Mobile Device, Application and Container Management
• It provides self-service capabilities (device enrollment, management, self-service password reset)
• Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
• Provides Multi-factor Authentication
• Provides AD-based, Cloud-based or Mixed Identity
• Works with Active Directory in a non-intrusive (no directory duplication) and secure way
• Provides a policy engine for the directory
• Provides Role-Based Access for Application access and Privilege Management
• Provides multi-geography, shared or dedicated hosting
• Provides an interface that
• Provides access in rich (web) and mobile clients
• Provides tenants with their own publicly-rooted certification authority
• Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
• Extensible by way of an SDK, customizations and branding.
• Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
• Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:

• Deal with servers in the DMZ
• Deal with understanding on premise federation technologies
• Deal with understanding app authentication or federation patterns
• Deal with publicly rooted certificates
• Pay for expensive MDM solutions
• Pay for 2-factor authentication solutions
• Worry about geographically located solutions
• Worry about language and branding
• Worry about having a split strategy for mobile devices

This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:

• What are the different Cloud IdPs and their pros and cons.
• A policy for cloud-based access controls
• A plan for service availability

We'll explore topics related to cloud in Security Corner.

User Suite Tour

Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.

Basics: Federation IS NOT Authentication

Commentary

Technology goes at a fast pace, unfortunately for IT professionals we are too busy at work to sit down and sharpen their skills.  Understanding the basics and frameworks about technology really can make a difference, however, I'm increasingly frustrated because I notice that even at architecture-level conversations I notice major knowledge like, knowledge of the problem, requirements, framing the conversation around security, understanding the basic standards and protocols.

How are you supposed to make technology decisions for organizations when you don't understand the basics?

Back in the day when I was a systems administrator,  I remember studying the inner works of Microsoft Exchange.  The framework was very basic, a client-server model that included

• Storage Providers
• Address Book Providers
• Messaging Transport Providers

This meant that when somebody was pitching to me a Fax solution that integrated with Exchange, I knew the key questions:  

• For usability - how does the fax addressing system integrates with the GAL
• For implementation - are there any client components?
• For troubleshooting - how do faxes get routed?

Another example in networking is the OSI and TCP/IP models.  I remember the good old Cisco Book by Oppenheimer "Internetworking Technologies Handbook" (I still recommend it) - basic things like in which layers flow control is important (layer 2) gave any IT professional a framework of what capabilities corresponded to each protocol.

This post is about the differences between Authentication and Federation.  Unfortunately when talking to folks that are looking at User Suite it's quite common for them to intermingle these terms.

What is Authentication?

Authentication is the process of verifying that a subject or program is who they say they are.  Notice the sequence here.  The's an assertion (who you say you are) and what are called "factors":

- Who you say you are  (username or unique identifier) - this is constant.

- Something you know (a password or paraphrase)

- Something you have (a physical token, smartcard, or one-time-password mechanism)

- Something you are (the patterns in your fingerprints, retina or voice)

Authentication happens directly.  There's a directory (like AD) that has a database of users and unique identifiers (UPN or sAMAccountName in AD), a password verification and protocol for authentication (Kerberos).   It happens every day, when you press Ctrl+Alt+Delete and type your password, when you access a file-share and silently get authenticated via Kerberos.  Strong authentication can be enforced by combining factors:  E.g. Something you know (password) + Something you have (hardware/software one-time token).

It happens when you go to Amazon, Facebook or when you do online banking.

What about Federation?

You've all seen the acronyms:  IdP, RP, SAML, Assertion, XML, etc.   What does it mean?

The best way to explain federation is to use an example.  

Let's introduce Joe Smith, he has a plane a reservation to Sidney Australia via Oceanic Airlines  (I wouldn't recommend that airline given the events in LOST), the sequence is typically as follows:

1. Joe Smith arrives at the airport and goes to the Oceanic ticket counter
2. He makes the following claim or assertion:  My name is Joe Smith and I have a reservation to Sidney, hands over a printout with this assertion, it includes a seat number and class.
   Let's think about this.  The ticket clerk does not hand Joe his boarding pass because the level of assurance that the information is accurate is very low. After all, somebody may be trying to impersonate Joe or he may not even have a reservation.  What if he arrived late or in the wrong date (this is known to happen).
3. The ticketing clerk confirms part of the assertion - Joe Does have a reservation, not only that, he is entitled to a premium seat 42B.
4. At this point, the clerk decides to confirm the other part of the assertion:  Joe's identity.  She asks, "can you please provide me with your passport?"  - because this is an international flight, the clerk verifies the Photo, Name/Last Name, DOB and Passport expiration date.  These fields have to match the system;  she checks Joe's face again, and proceeds to issue a boarding pass.
   Now, let's think about what happened here.  
• The airline can't confirm directly that Joe is who he says he is.  
• The airline relies on the US government's Passport Office's process and that they did their due-diligence in making sure they issued the passport to the correct person.  This makes the USPO the Identity Provider and the airline is the Relying Party. The airline has a trust relationship with the USPO.
• This means that the process in the USPO performs the authentication that Joe is who he said he was prior to issuing the document.
• The ticket also includes an entitlement.  Joe is entitled to seat 42B in the economy section.

This is Joe Smith's Boarding Pass.  Once his identity is verified, he'll be issued one.

Now we can look at the way Identity Federation is implemented in the the context of SaaS applications:

SaaS applications and many on premise applications can authenticate users directly OR support federation via a popular protocols like SAML.  This means that they can be a relying party.  When configuring an application for Federation, you'll be asked about the building blocks like:

• Certificate:  This is a key building block for a federation agreement or trust relationship.  The identity provider and the relying party establish the agreement by using a publicly rooted certificate.  If this certificate expires, the federation trust is broken.
• Assertion or claim details:  how is it going to be composed?  It could be as simple as a username or email address, or as complex as email, role, purchasing level, etc.  It's all based on the app.  In addition, a schema (XML) that provides the definition of assertions may need tob e provided.
• Redirection URLs:  Where to forward the encrypted claim or assertion;  This could be login, logout or error.  These typically are the Identity Provider's URLs to process the assertions and handle session or error management.
• Provisioning options:  Some apps support provisioning models like SCIM. More on this on a later posting.

It's important to understand that many SaaS apps allow mixed scenarios in which they can authenticate locally or using Federation at the same time.

How it works - just like the airport scenario, but online.

1. The subject or user attempts to access the application by providing an assertion (e.g. email address or username, e.g. joe.smith@corp.contoso.com)
2. The application (relying party) looks at its internal rules and sees the federation rules for that user.  Assuming SAML.
3. The assertion is encrypted and forwarded to the login URL to be processed by the Identity Provider.
4. The identity provider performs its internal checks (is the user active, allowed to access the app, etc - all based on the assertion)
5. The identity provider returns the verification result and any additional information required.
6. The subject is granted or denied access to the application and maybe depending on the application, information about entitlements may also be provided.

Here's the mapping of the Add Application Wizard for Centrify to enable SAML Federation for Salesforce:

Centrify User Suite - Application Wizard for Salesforce - it takes literally minutes to set up.

Centrify User Suite leverages Active Directory on the customer's premises to perform the validation or authentication, this means that the enterprise keeps control of key directory attributes and password data.

Recommended Reading

A Guide to Claims-Based Identity and Access Control, Second Edition

Although Microsoft-centric, the book does a great job and uses very good examples.  It's a free download (see link) or you can always get the hardcopy.

Basics: What constitutes a cloud identity?

Hola!! from Panama City.  At Centrifying we are tasked to represent Centrify in the ISACA Latin America CACS 2014.
We had a chance to educate the attendees in the challenges and concepts of cloud identity and SaaS access controls security.

Background

This new series focuses on Identity as a Service (IdaaS).  As you probably know by now, Centrify has two product lines Server Suite and User Suite.  The first basic topic is to understand what constitutes a cloud identity.  At a basic level, the identity that supports a SaaS application can be as simple as a unique identifier and a password; However, that doesn't translate into a very valuable app.

So what's the problem with SaaS apps as it relates to Identity?

Since SaaS apps extend the IT boundaries beyond the on premises data center over the Internet the most basic issues are around timely provisioning.  Once a user leaves the company if the offboarding process is not timely and efficient, the organization is exposed to a potential data loss.  Unfortunately, just like the issue with the  heterogeneous datacenter, the solution sets today promote capability and process fragmentation and here's where Centrify can help.  Furthermore, let's explore the problem by at further length.

The typical cloud IdaaS providers may make you think that the issue is just Cloud Identity and SSO (federation), but the problem goes beyond that.  Let's explore some aspects:

• License assignment:  this topic impacts the bottom-line.  How does your process makes sure that the user is properly licensed (no more than what they need), and that licences are administered accordingly.  

  

  Timely license management has cost implications

• Role, Profile or Group management:  Depending on the application, entitlements determine what the user can do within the application. This is key for sound security.
   

  

  Salesforce provides access to different functions based on the user's profile

• Multi-factor Authentication (MFA) and 2-Step-verification:  These capabilities are increasingly a must because they are the foundation for different types of policies.  The recent consumer services data-breaches illustrate that need.

  

  MFA and 2-step verification are a must nowadays, the issue is - how to standardize.

• Policies:  Each SaaS provider has a different way to deal with policies.  Would it be nice to do it in a single management framework? and wouldn't it be nice if it's enforceable across all endpoints including mobile devices?

  

  Different SaaS providers provide different policy frameworks

• Support for Mobile Device Management (MDM) Mobile Application Management (MAM) and Mobile SSO:  This capability is also a must;  as phones and tablets become more powerful, mobile computing is a big tool in the information worker arsenal.

  

  MDM has become commoditized, MCM is looking for a standard, but MAM and Mobile SSO are growing

Is there a Unified Solution out there that is friendly to Active Directory?

So the question is - What if there's a solution out there that allows you to use an existing infrastructure (AD) to solve all these issues without the need of additional infrastructure or the need of complex Identity synchronization?   

YES!

That is what Centrify User Suite is all about! The next posts will focus on the service and 3 apps: Google Apps, Office 365 and Salesforce.  The first post will explore what Federation is and isn't.  Look for the Cloud-labeled articles.