Identity Center and attribute mapping for ABAC

0

I am trying to enable attribute-based access control (ABAC) using IAM Identity Center. However, I am a bit confused on how to setup attribute mapping in Identity Center. I wanted to used user's Department attribute for it, but I am still receiving Access Denied. I am using CDK in TypeScript and I have the following configuration for mapping.

new CfnInstanceAccessControlAttributeConfiguration(stack, 'attribute-config', {
    instanceArn: INSTANCE_ARN,
    accessControlAttributes: [
        {
            key: 'Department',
            value: {
                source: ['${path:enterprise.department}'],
            },
        },
    ],
});

Then I set up following permission set.

new CfnPermissionSet(stack, 'permission-set', {
    instanceArn: INSTANCE_ARN,
    name: 'MyPermisionSet',
    inlinePolicy: new PolicyDocument({
        statements: [
            new PolicyStatement({
                effect: Effect.ALLOW,
                actions: ['s3:ListAllMyBuckets'],
                resources: ['*'],
            }),
            new PolicyStatement({
                effect: Effect.ALLOW,
                actions: [
                    's3:ListBucket',
                    's3:GetBucket*',
                ],
                resources: ['*'],
                conditions: {
                    'StringEquals': {
                        'aws:ResourceTag/Department': '${aws:PrincipalTag/Department}',
                    },
                },
            }),
        ],
    }).toJSON(),
});

Finally, the objects are created such that

const devBucket = new Bucket(stack, 'DevBucket');
Tags.of(devBucket).add('Department', 'Dev');
const itBucket = new Bucket(stack, 'ItBucket');
Tags.of(itBucket).add('Department', 'IT');

I created user in Identity Center and assign the account and permission set to him (also set his Department). I can list the buckets, but I can't view objects in that bucket (I can view objects if I remove the condition from the permission set, so the condition must be the problem). I looked for the operation in CloudTrail, and the only session context attributes are

"attributes": {
   "creationDate": "2024-09-01T20:09:58Z",
   "mfaAuthenticated": "false"
}

Note that the access doesn't work even if I change the source to "${path:userName}" and change the bucket tag according to the username of the user. How can I enable such setup please?

I am probably confused of which values as source I can use. As far as I understand, I can use values according to the [Enterprise User Extension Representation](https://datatracker.ietf.org/doc/html/rfc7643#section-8.3] specification, but that applies only for SCIM. However, Supported user and group attributes in IAM Identity Center specifies these attribute as general that can be used with any directory (Identity Center directory, Microsoft AD directory, as well as external IdP). But then in Attribute mappings for AWS Managed Microsoft AD directory, only subset of them is mentioned. Moreover, some of them as path prefix, while others have dir or user. What is the difference and how I know which to use when? E.g. some examples use ${path:enterprse.department} source but in the RFC7643 there is urn:ietf:params:scim:schemas:extension:enterprise:2.0:User attribute. Can somebody please explain this or send me some relevant sources? I am a bit confused here.

profile picture
asked 11 days ago67 views
2 Answers
0
Accepted Answer

Not all resources and resource actions support the global condition key asw:ResourceTag.

Your actions of ListBucket, GetBucket* do not support it.

Refer to the Service Authorization Reference for what condition keys are supported: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html

AWS
answered 10 days ago
profile picture
EXPERT
reviewed 9 days ago
  • Thank you, you are right. When I switched from S3 to EC2 and StartInstances and StopInstances actions it works as expected.

    Would you please be willing to further clear up how the values in the policy works? Like where to use path and why the Department tag is under enterprise.department value?

  • My understanding is that: dir: is applicable only when you use AD as identity source path: is applicable only when you use external IdP and SCIM user: can be used pass attributes to downstream SAML applications (and only user: attributes can be used, not path: and dir:)

    department is put under enterprise I guess is just following the model in SCIM

0

I have a very similar but different use-case. My ABAC is working but different from yours. I have some ideas if you are interested.

I suggest you take a step back and implement one Identity Center Principal property on the S3 and get that working with a hard coded compare.

  1. Next step: add the Principal attribute to an S3 resource tag. My use case doesn't need this step but IMHO if you get one thing working it will all start making sense.

In my case I used one Principal property from the RFC and connected it to my S3 bucket(s). I added a "userType" from the RFC and gave it a value that was similar to other ones. It then showed up in Identity center as "User type". I was able to give it a value of "XX" and then able to add it to on IAM policy.

If interested I can give you a few more specifics but my recommendation is to start simple.

Note there are some things in your policy I don't understand how you created. I would start with the GUI not JSON when starting this migration. Maybe an array of resources makes sense when the array is "['*']" but why since resource: '*' means all values. I am truly confused what you really want it to do.

Allen S
answered 10 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions