In Discovery: IIQ AWS Connector - Support for AWS IAM Identity Center

Announcements Product Research
, ,
1

Business Problem

AWS IAM Identity Center offers centralized access management for multiple AWS accounts and business applications, enables single sign-on functionality and streamlines user access across AWS services. It seamlessly integrates with diverse identity sources, allowing efficient creation and management of user identities within IAM Identity Center’s identity store.

The SailPoint IdentityIQ AWS connector is limited to supporting user access management for AWS IAM users. It does not support access management for AWS IAM Identity Center users, limiting its capability to efficiently govern and secure access within an AWS Organization.

Sound Familiar?

If this is a problem that impacts your organization, use our Ideas Portal to cast your vote for this Idea. Here you can view currently submitted ideas, add comments for your specific use cases around this problem, and vote!.
Idea: Connector support to AWS IAM Identity Center

How You Can Help

We are continuing to validate our understanding of the problem space and solution. In addition, we are conducting research calls focused on validating our designed solution, better understanding the desired user experience, and ensuring we hit the most common customer use cases.

Our Product Management team would love to hear from you! Here’s how:

  • Voice your thoughts, questions, comments, and concerns right here in this topic.
  • Vote on the idea linked above.
  • or schedule a call if you feel the need to discuss this topic in private, and provide insights specific to your business problem and use cases. If you don’t see a calendar opening that aligns with your availability, feel free to send me a direct email.
2 Likes
2

Hello,

This sounds great as we exactly have this need in our environment, but with IdentityNow :wink:
In terms of business need, in our case it is pretty simple. We are using Identity Center to use Azure AD auth for AWS users !

Hope to ear about this quickly for IDN !

3

Hey Alex, an AWS IAM Identity Center connrector already exists for Identity Security Cloud (aka IdentityNow) as part of the SailPoint CIEM offering :slight_smile: No need to wait for that.

4

I think this conflicts with federated users. In an AWS Organization with multiple AWS accounts. I’d like to know how this differs from the use case below…

With federated users, there’s no need for SCIM or managing the lifecycle of users because they don’t exist. Each aws account has an IDP configuration an a predefined set of IAM Roles with the sts-assume role for SAML. Access is then determined within the identity provider and sent via SAML with a list of aws accounts and each role the user is authorized to access.

The only exception may be service accounts that require access keys, but that’s a separate problem.

The initial cost to adopt this architecture (eng hours) is to come up with a repeatable method or bootstrap to adequately scale the necessary IAM Roles in AWS, adding the groups to your identity provider, and create the access profiles for those entitlements in Sailpoint.

For example, you have an AWS Org with 3 accounts. The parent and 2 eng sub-accounts, each with the same collection of roles \ policies.

AWS Org
Org AWS Account (1234567890 – Alias: Core)
- Role: Admin
- Role: Read
- Role: Write
- Role: Security

  • Sub AWS Account (2345678901 – Alias: Data)
    - Role: Admin
    - Role: Read
    - Role: Write
    - Role: Security
  • Sub AWS Account (3456789012 – Alias: Eng)
    - Role: Admin
    - Role: Read
    - Role: Write
    - Role: Security

Identity Provider

Within your identify provider, you adopt a mechanism for translating group names, attributes, etc to format the SAML assertion to a collection of ARN’s. One method supported by Pingfederate, Okta, etc is to adopt a naming convention. Something to the affect of…

<prefix>_<account_id or alias>_<role>

Sample Groups:

  • aws_core_admin
  • aws_core_read
  • aws_core_write
  • aws_core_security
  • aws_data_admin
  • aws_data_read
  • aws_data_write
  • aws_data_security
  • aws_eng_admin
  • aws_eng_read
  • aws_eng_write
  • aws_eng_security

These “entitlements” may then be aggregated into Sailpoint and distributed to manage birthrights, requests, etc.

SAML \ IDP

Upon sign-in, the IDP formats a list of applicable groups the user is a member of and transforms them to allow a selection of which accounts and roles the user may start a session with.

      <saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/Role"
                       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:type="xs:string">arn:aws:iam::1234567890:saml-provider/okta,arn:aws:iam::1234567890:role/admin</saml2:AttributeValue>
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:type="xs:string">arn:aws:iam::1234567890:saml-provider/okta,arn:aws:iam::1234567890:role/aws-corp-com-db-sailpoint-write</saml2:AttributeValue>
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:type="xs:string">arn:aws:iam::1234567890:saml-provider/okta,arn:aws:iam::1234567890:role/view</saml2:AttributeValue>
        <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:type="xs:string">arn:aws:iam::1234567890:saml-provider/okta,arn:aws:iam::1234567890:role/write</saml2:AttributeValue>

image
image444×711 11.6 KB

5

Hey Brian, the use case you are describing is the “older” federation model of AWS:

  • You would connect your IdP (Azure, Okta, Ping, etc) directly to your AWS accounts.
  • You would map some IdP Groups to AWS IAM Roles.
  • AWS IAM simply has a number of federated IAM Roles that trust your IdP.
  • There is no visibility from an AWS perspective of who can assume actually those Roles, with than information existing solely in your IdP.

AWS now offers a new way of managing access to AWS Accounts (both federated and non-federated) through AWS IAM Identity Center (previously known as AWS SSO).

AWS IAM Identity Center acts as an intermediate step between your IdP and your AWS Accounts. Essentially your IdP (or other tools) can provision/synchronize users & groups into AWS IAM Identity Center. The mapping of group to role+aws-account (referred to as permission sets and account assignments) happens inside in AWS IAM IC as opposed to your IdP.

The idea with AWS IAM Identity Center is:

  • It’s a single entry point for all your AWS accounts. You only need to connect your IdP once and not to each and every AWS account.
  • You have full visibility of federated users, groups and assigned access within AWS. You no longer have to rely on 2~3 different locations to understand who has access to what.
  • AWS IAM IC also automatically manages all the federated IAM Roles in each AWS Account for you. All you need to do is create permission sets and assign them to AWS IAM Identity Center Users/Groups over one or more AWS Account(s).

Today, the IdentityIQ AWS connector does not have the capability to manage AWS IAM Identity Center Users, Groups & Permission Sets. It can only manage local AWS IAM Users, Groups & Policies - hence the new capabillities in discovery here.