Active Directory Single Sign-On (SSO) on AWS with Bitium

Bitium, an APN Technology Partner, offers an enterprise-grade solution for single sign-on, application and user management, password management, directory integration, and security and compliance.  By utilizing the Bitium software as a service (SaaS) solution, we are going to demonstrate the integration of Microsoft Active Directory (AD) logins with the Amazon Web Services (AWS) Management Console via the Bitium SAML implementation.

A popular request when implementing a new system is, “can we use our existing directory for authentication?” Running independent user lists can become quite a hassle.  For example, when an employee switches departments, when you add a new staff member, or when a staff member takes on additional responsibilities, you can either update the information in your single central source for AAA (authentication, authorization, accounting), or you can maintain independent lists of users with varying settings for items such as password requirements, password aging, and when to audit users.

Wouldn’t it be easier if everything just worked together?

In this post, we are going to run through the process of deploying the Bitium SaaS offering as an authentication solution. Using this application, you’ll be able to administer AWS Management Console access directly from your Active Directory administration console.  Many organizations currently rely upon Active Directory for their corporate directory solution, and while this post focuses on that one form of directory integration, Bitium provides solutions from LDAP integrations to third party SAML integrations. This expands the capabilities to define authentication sources as any IdP (identity provider) that uses standardized SAML, LDAP, Active Directory, or Google Apps methods of authentication.  For example, the Bitium website explains the Bitium features that enable the integration of Google Apps with AWS.

Establishing the Organization Domain for the Blog Example

In this example, our organization domain is, “JF.UNICORN.RENTALS”.  This is identified by the email address used to sign up for the Bitium account.  I have also created the Active Directory domain as “JF.UNICORN.RENTALS”.  We will assume a public website of http://www.jf.unicorn.rentals with static images stored at http://images.jf.unicorn.rentals.

Setting Up Bitium with AWS and Microsoft Active Directory

To start, we want to identify the user and group permissions necessary for the individual AD groups and users.  We are going to assign groups based upon departments.  Here is the group configuration we will utilize for the example:

Active Directory Group Name:

                AWS-Admins

                AWS-Devel

                AWS-QA

                AWS-Marketing

                AWS-DBA

For the first steps, we need to create the groups listed above in Microsoft Active Directory.  You can view an example in the screenshot below:

Now that we have the groups created, we want to add some users to those groups.  In the examples below, we will be using the following user and group mappings:

BobTheAdmin -> AWS-Admins

DaveTheDba -> AWS-DBA

SteveTheDevel -> AWS-Devel

CarlFromMarketing -> AWS-Marketing

DanFromQa -> AWS-QA

Now that we have the AD configuration necessary for testing, we need to integrate our directory into the Bitium service.

If you don’t already have an account, go to the Bitium website to create a new organization.  You can start a free trial to test the example implementation.

When you click Start a Free Trial, you’ll be asked to register with an email address. The domain name from your email address will be used as the DNS for the Bitium organization you create.  For example, when I signed up for an account, I used the email address:

fontesj@jf.unicorn.rentals

This created a Bitium organization for my login, titled “jf.unicorn.rentals”.  If your organization has already signed up from the corporate email domain for a trial account, you may need to choose an alternate domain name for the trial.  You cannot use a public, personal email account, as your organization will not have control over accounts in use by email systems such as Gmail, Yahoo! Mail, and so forth.

Once you enter your email address, you’ll be sent a confirmation email containing initial instructions for getting started with Bitium. Make sure to confirm your email, and perform the initial tasks.  When this is complete, you’ll have a trial account with the capabilities and features of the Bitium Unlimited Plan.  The Active Directory integration components are available through the Bitium Business Plus and Bitium Unlimited account plans.  Additional information about plan differences can be found on the  Bitium website.

Integrating Bitium with Active Directory

Now that we have the Bitium account active with your newly created organization, we’ll want to first start with the integration of Bitium with your Active Directory servers on AWS.  Before we can start the integration, we are going to have to make at least one Active Directory server available to the Bitium SaaS infrastructure.  If your Active Directory server does not have a public IP address attached, you’ll need to allocate a new elastic IP address (EIP) and attach it to the AD server now.  Alternatively, you can utilize other methods for interaction (such as NAT forwarding), but that is beyond the scope of this article.  To assign a new EIP to your instance, you can follow the instructions in the AWS documentation.

To begin the integration, you’ll want to follow the steps outlined in the Bitium Support Center.  Be sure to enter the public DNS or EIP assigned to the Active Directory instance into the *Server box in step 4 of the instructions.  Additionally, you will want to record the IP address provided below the box as shown in the screenshot below:

Configuring Active Directory Instance Access from Bitium

You’ll now create an AWS security group that will allow for the Bitium connectivity, and attach that AWS security group to the Active Directory instance.  In the AWS Management Console, click EC2, and then click Security Groups as shown below:

You will now need to utilize the public IP address from Bitium that you recorded earlier.

For the security group name, we want to use something easy to remember. For this example you can choose “Bitium-AD-SG”.  The description should reflect the purpose of the security group.  You will also want to identify the Amazon Virtual Private Cloud (Amazon VPC) in which the AD server is running from the VPC drop-down list.  Finally, for inbound rules, you will want to add two entries.  First, add the LDAP TCP protocol and set the TCP port to 389 and list the source as a custom IP with the recorded Bitium IP address mentioned above.  Add a second line with the same custom IP and Bitium IP address but with a TCP port of 636.  Once you have completed this step, click Create to finalize the creation of the security group.

Now that we have the security group created, we’ll need to attach the group to the running Active Directory instance.  In the AWS Management Console, go to your list of EC2 instances and highlight the Active Directory instance.  Click Actions, Networking, and then Change Security Groups as illustrated below:

Highlight the newly created security group, and then click Assign Security Group.

Adding Active Directory as a Bitium Organization Directory

Now that we have Active Directory configured for use via the instructions from the Bitium link provided above, and the Bitium solution is able to communicate with our Active Directory server, we need to sync the directory to our Bitium account.

Although our Active Directory domain has been added as an authentication source, we still do not have the contents of the directory (users and groups) synced from our AD implementation to Bitium.  For this to happen, we are going to need to add our AD directory as a Bitium directory.  Note: We are using “Groups” to define what AD refers to as Organizational Units (OUs).

In the Bitium administrative console, click Directories, and then click Add a Directory:

You will then be presented with a drop-down list of currently available options.  Select Active Directory from the list.  On the next screen, make sure that the status is set to On, and then click Add Directory.

We will now perform an initial sync of the users and groups to import them into Bitium.  Click sync now as shown below.

We’ll now need to link the Active Directory groups for use within Bitium.  From the Bitium administrative console, click Groups, and then click Link Groups.

Since we prefixed our groups with “AWS-*”, we can enter “AWS” in the search box on the next screen to get a full list of groups that we want to link.  Once you have those groups listed, click Add All as shown below.

Once you have the groups listed, click Done.

You should now have the Active Directory groups listed in your Bitium groups as shown here:

Creating the AWS Identity Provider / Bitium SAML Integration

We’ll now integrate the Bitium solution with our AWS account to allow for the use of our Bitium organization as an AWS identity provider.  You can find instructions for accomplishing this task in the Bitium Support Center.

AWS Roles and Policies

Now that we have Bitium functioning as the SAML identity provider for your AWS Management Console logins, we’ll need to identify the rules to apply to each user.  For each Active Directory group, we’ll want to apply an individual AWS Identity and Access Management (IAM) role and attach an IAM policy to ensure that users only have the access that they need to perform tasks associated with their positions.  For example, we have CarlFromMarketing in our list of users.

Carl is in the AWS-Marketing group and needs to have access to update items stored in Amazon Simple Storage Service (Amazon S3), as these are going to be static content items available via Amazon S3 for public viewing.  As we mentioned previously, static images are hosted from http://images.jf.unicorn.rentals, which is an Amazon S3 web-hosted bucket.  On the other side, we have the AWS-Admins group, which consists of administrative users who will need full access to the AWS Management Console. Members of the AWS-Devel group will have full access to Amazon EC2, as this group will typically need to start and stop/terminate instances used for development.  The AWS-QA group consists of quality/test team members who would typically need read-only access to services.  As such, the QA group will have both Amazon EC2 read-only access and the ability to perform Amazon EC2 report generation.  Finally, the AWS-DBA team consists of database administrators within our organization.  We are going to assume that this group uses Amazon Relational Database Service (Amazon RDS) for their database needs and thus does not need access to Amazon EC2 or other services.  This group will have full Amazon RDS permissions but no access to other services.

The first thing we want to do is to create any necessary policies that do not exist.  For the AWS-Admins, we will be using the preexisting “AdministratorAccess” policy.  The AWS-DBA group will use the “AmazonRDSFullAccess” policy.  The AWS-Devel group will have the “AmazonEC2FullAccess” policy.  The AWS-QA group will have two policies, the “AmazonEC2ReadOnlyAccess” policy and the “AmazonEC2ReportAccess” policy.  Finally, we need a policy for the AWS-Marketing group that only needs access to add, update, and delete S3 bucket items in one bucket.  Furthermore, this group should not be permitted to perform advanced features like changing bucket permissions.  For these requirements, we’re going to have to create our own policy that will later be attached to a role for the AD user group.

Creating an IAM Policy

To create the necessary policy for the AWS-Marketing group, we want to log in to the AWS Management Console and click Services, and then IAM.  Next, click Policies on the left, and then Create Policy.

To build this policy, we are going to use the AWS Policy Generator, which you can select on the next screen.

In the next screen, set the Effect to Allow.  Next, select Amazon S3 from the AWS service list.  From the Actions list, we will identify the actions that the AWS-Marketing group should be able to perform.  From the list, select these actions:

AbortMultipartUpload

DeleteObject

GetObject

ListBucket

ListMultipartUploadParts

PutObject

Next, we want to make sure to restrict these permissions to the images bucket that serves the content to the http://images.jf.unicorn.rentals/ website.  To accomplish this, set the ARN of the policy to the S3 bucket name ARN: arn:aws:s3:::images.jf.unicorn.rentals/*

Once those settings have been entered, click Add Statement.

Once complete, click Next Step.  Here you will be able to review the policy created by the Policy Generator.  For the policy name, enter a logical value.  In this example, we will use “Bitium-Marketing-Policy-001”.  Enter a description for the policy, and then review the created policy document.  Next, click Create Policy.

Creating the IAM Roles

Now that we have the AWS-Marketing group policy created, it is time to get the IAM roles created for each group.  Here is the group-to-policy mapping:

AWS-Admins -> AdministratorAccess

AWS-Devel -> AmazonEC2FullAccess

AWS-QA -> AmazonEC2ReadOnlyAccess, AmazonEC2ReportAccess

AWS-DBA -> AmazonRDSFullAccess

AWS-Marketing -> Bitium-Marketing-Policy-001

In the AWS Management Console, click Services, IAM.  From the menu on the left, click Roles and then Create New Role.

For the role name, I’m using the naming convention Bitium-Admins, Bitium-Devel, etc. This will help to clarify the purpose of each new role created.  We’ll start off by creating Bitium-Admins, so enter that value in the Role Name text box.

On the next screen, click the option button next to Role for Identity Provider Access.  Then click Select to the right of Grant Web Single Sign-On (WebSSO) access to SAML Providers.

On the next screen, make sure that the SAML identity provider you created earlier for Bitium is selected in the drop-down list, and then click Next Step.

Verify the trust role on the next screen, and then click Next Step.

Here is where we want to attach the policies we listed earlier.  For the Bitium-Admins IAM role, we want to check the box for AdministratorAccess.  For groups like AWS-QA, you can select multiple boxes.  When creating the AWS-Marketing role, search for “Marketing” in the policy list to quickly find the policy to attach.

We have to create each role individually.  For this first example of creating the Bitium-Admins role, just select the AdministratorAccess check box.  Once you have the proper policy selected for each role, click Next Step.

The next screen lets you review the role you are about to create.

For each IAM role that we create, we will need to keep a record of the IAM role name, as well as the IAM role ARN somewhere for later reference (such as a Notepad file, vim file, text edit file, atom file, etc.).  Once you are done evaluating the information, click Create Role.  You’ll now repeat this process for each group identified earlier in the mapping, using the same naming convention we used for AWS-Admins:

AWS-Admins -> Bitium-Admins

AWS-Devel -> Bitium-Devel

AWS-QA -> Bitium-QA

AWS-DBA -> Bitium-DBA

AWS-Marketing -> Bitium-Marketing

Your list of roles should look like this:

Mapping Active Directory Groups to AWS Roles in Bitium

We now have to map the permissions that each user will have once they utilize the Bitium SSO capabilities to log in to the AWS Management Console.

Navigate to your Bitium administration dashboard.  Click Manage [DOMAIN] and then Manage Apps.

On the next page, you’ll see an entry for the Amazon Web Services Bitium App that you created earlier.  Under the Subscriptions heading, click on the link for # assigned.

In the next screen, click Single Sign-On.

From this screen, we’re going to link our Active Directory groups to the IAM roles that define their associated access levels within the AWS Management Console.  Under AWS IAM Role ARN, click Add another field.  This will bring up an area to add the role ARN from AWS. Then select the Active Directory group it maps to, from the drop-down list on the right.  We’ll now need to enter each ARN we saved earlier in the box on the left and then select the group mapping on the right.  For example, we would first enter the mapping for the Bitium-Admins as it corresponds to the AWS-Admins Active Directory group.  Thus, in the box on the left, enter the IAM role ARN (as recorded earlier) into the box.  On the right, select the AWS-Admins group from the list of groups within Bitium, as shown below:

Click Add another field again to repeat this step for all the IAM role -> Active Directory group mappings from our list:

Bitium-Admins -> AWS-Admins

Bitium-Devel -> AWS-Devel

Bitium-QA -> AWS-QA

Bitium-Marketing -> AWS-Marketing

Bitium-DBA -> AWS-DBA

When you’ve completed the entries for each mapping, the Bitium SAML configuration should resemble this:

To save the configuration, scroll to the bottom of the page and click Change Provider.

We’re now set to use the Bitium Single Sign-On application.  In a web browser, you can now test the capabilities of the application and expand it for use within your organization.

Pulling it All Together

As we have shown, you can utilize a multitude of authentication sources and directory options in order to integrate AWS Management Console logins via Bitium.  There are additional areas available for further reading, such as integrating the AWS Command Line Interface (CLI) with Bitium, as described on the Bitium website. This feature allows employees to log in to AWS through the command line when their AWS account is using SAML authentication.

I’ve explained how you can organize your user base into the groups necessary to restrict access to specific services and features, and how to integrate existing directories as well as map existing groups and users.  You can now define and utilize the IAM roles and policies to create the restrictions that are right for you.