Symantec SiteMinder: Federating with Amazon AWS

This guide is intended to explain how to establish a federation partnership with Amazon AWS using Symantec SiteMinder. The below instructions will walk through a step-by-step process to set up entities in Symantec SiteMinder, create the Partnership, create the Amazon AWS objects, and set up the users to log in. 

Prerequisites

  • Federation capabilities are deployed in the SiteMinder Environment
  • Protection policies for federation authentication URLs are in place.
  • You have access to the Amazon AWS Console
  • Identity Provider Signing Certs are already in place on the Policy Server

Tasks

  1. Set up entities in SiteMinder
  2. Create the Partnership
  3. Create the Amazon AWS Objects
  4. Set up users to log in

Task 1 – Setting up the SiteMinder Entities

  1. Log in to your SiteMinder Admin UI and Navigate to the Federation Entities section.

  2. If you do not currently have an IDP Entity created, we need to create one. Create a local IDP Entity and fill out your base URL and Name ID Format information. The base URL is whatever URL your federation agent is listening on and if you are unsure what Name ID format to use, just accept the default unspecified.

  3. Next we need to get the metadata for Amazon AWS to import and create our SP Entity.

    Navigate to https://signin.aws.amazon.com/static/saml-metadata.xml and copy the content of the metadata into a text file and save that file as a .xml.

  4. In the SiteMinder Admin UI, go back to the Entity section and click the Import Metadata button and create the remote SP Entity.

  5. You should now have your local IDP Entity and the remote SP Entity.

Task 2 – Create the Partnership

Now that we have the entities created, we can create the Partnership and export it in preparation to create the Amazon AWS console objects.

  1. Navigate to the Partnerships section in the Admin UI and create a new IDP -> SP partnership.
  2. Select the User Directory object that you want to associate with the partnership.
  3. Continue the creation process until you get to the Assertion Configuration screen. Configure the following.
    1. Name ID Format: Persistent Identifier
    2. Name ID Type: User Attribute
    3. Value: your identifying user attribute
  4. Create 2 Assertion Attributes (We will talk about these during part 4)
    1. Assertion Attribute: https://aws.amazon.com/SAML/Attributes/RoleSessionName
      1. Retrieval Method: SSO
      2. Format: Unspecified
      3. Type: User Attribute
      4. Value: use the user value you want as the display name
    2. Assertion Attribute: https://aws.amazon.com/SAML/Attributes/Role
      1. Retrieval Method: SSO
      2. Format: Unspecified
      3. Type: User Attribute
      4. Value: use an empty value in the user store

  5. You can accept the defaults for the SSO and SLO section. This information is filled in by the Entity Information.
  6. Set the Signing and Verification certificates if they were not set by the Entities.
  7. Activate the partnership.
  8. After you activate the partnership, export the metadata.

Task 3 – Creating the objects in Amazon AWS Console

In this section we need to log in and start creating all of the configurations for the Amazon side of the partnership.

  1. Log in to your Amazon AWS Console. Go to the IAM section. Select the Identity providers tab.
  2. Click on Add Provider and select the SAML option, name your new provider, and upload the metadata that we exported previously.
  3. Next we need to set up a Role in the AWS Console. Click on the Roles tab and create a new role.
  4. Select the SAML 2.0 federation choice at the top. The screen will change to allow you to select the SAML Provider you just made. Check the box to allow access to the AWS Console. This will auto fill the Attribute and Value fields.
  5. Add permissions to the role you’re creating. In this case we’re setting up federation for administrators into the AWS Console, so we chose the AdministratorAccess permission.
  6. At this point you can add tags if you’d like. Otherwise continue to the last step to name the Role and submit it.

Task 4 – Setting up users to log in

For this section, the configured Assertion Attributes will be referred to as follows:

  • https://aws.amazon.com/SAML/Attributes/Role = Role
  • https://aws.amazon.com/SAML/Attributes/RoleSessionName = RoleSessionName

Be sure that the official name in the configuration are the full URL values and not shorthand. Amazon’s Assertion Consumer Service looks specifically for those URL values. They are case sensitive as well.

Before we get into the steps for this section, we need to go over how Amazon AWS actually federates users because it doesn’t work in the same way that most partnerships do.

Typically, a federated user needs to exist in both the IDP and the SP locations. The difference is just where the password is managed. We use a common attribute value to associate the two user instances to identify and connect them to establish a valid session.

However, with AWS, you don’t need a user to exist in the AWS console to federate. It works by creating a temporary user session based on the Role that we made in the last section. Essentially, when the SAML assertion is created after you authenticate against the IDP, those assertion attributes that we defined in our partnership will be providing AWS with the Role and Permissions to associate with our temporary session and the RoleSessionName attribute will define what the display name for that session will be.

These next few steps are going to demonstrate how to designate that information in the user’s account. For these  examples, we will be using JXplorer to manually add the user info to a user in an LDAP directory. The actual user attribute name is arbitrary, so long as those attributes are identified in your partnership settings. For example, we are using homePhone and description to identify the Role and RoleSessionName attributes, but you may use a custom attribute for these.

  1. Open Jxplorer to the user you want to enable for federation.

  2. In the attribute that you defined for your Role AssertionAttribute, we need to add the object IDs that are in AWS. Open the Console for AWS again and go to the Roles section. Click the Role we made for federation and copy the Role ARN value.
  3. Paste that information in the attribute for a user that’s associated to the Role assertion attribute.
  4. Now we need to add one more piece to that value before we submit it. In the AWS Console copy the ARN of the Identity Provider that we created for the partnership.
  5. Paste that value into the user attribute behind the Role ARN, separated by a comma. There should be no spaces in this value.
    for example, my value now looks like this: arn:aws:iam::102495008179:role/Federated-Access,arn:aws:iam::102495008179:saml-provider/ISX
  6. Add a value to your attribute mapped to the RoleSessionName and that will complete the preparation for this user and you can test that partnership now using the IDP initiated URL.

    The images below indicate the way that AWS translates the user information into the temporary session.

Now that you have that Role ARN Identity Provider ARN combination value, that value will be the same for all users that are trying to federate into AWS under those same access permissions. If multiple Roles need to be added to a user to define their permissions, then they need to be in that format as well.

Looking for additional help with federating with Amazon AWS? ISX Consulting is an elite IAM security firm that offers boundless expertise in a range of cybersecurity and business process services, including Symantec Siteminder integration and management. Take your interoperability to the next level, and contact an ISX consultant today.

ISXSymantec SiteMinder: Federating with Amazon AWS

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *