ABAC with IAM identity Center and Entra. Best approach's?

IDC doesn't seem to support passing an array of group memberships or any other type of naturally scalable data structure to session properties for evaluation in authorisation policies. This document article: https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac-attributes.html says in the "Note" box that only single-valued attributes are supported by the whole ABAC mechanism in IDC:

Use a single-value attribute for your key, for example, Manager. IAM Identity Center doesn't support multi-value attributes for ABAC, for example, Manager, IT Systems.

I believe you're right in that having to configure a separate attribute for every PIM-governed group/role membership that's going to be passed from Entra ID to IDC isn't likely to scale well. Also the bot's suggestion about mapping the groups/roles to IDC permission sets would just be a variation on the same theme, only substituting the separately configured permission sets for the separately configured attribute mappings, not solving or even mitigating the issue.

So, i've tested both methods, using atttributes, ( which you have to configure a conditional attribute for every role ).. and also tested using groups that are syned with scim, When you Pim Up into a group, Scim will use Provisioning on demand, to push the change to the AWS. The time it takes is variable, in our tests we saw times between approximatley 40secs and 4 minutes. There is a provsio, that it will only do a max of 5 pims per 10 seconds. If you do more than that they then fall back to the regular 40 minute sync period.

Using attributes, ( which can be mapped to a principal tag ) the UX is considerably faster. As soon as a user logs in, they can use the roles.. However this requires, that you create two groups. One group which users are permantly a member of, which gets used in the 'group/permissionset/account' mapping, and one that creates the conditional attribute. Its faster, but its consierably more complex, and i'm definately worried about how far it can scale.

Implementing Attribute-Based Access Control (ABAC) with AWS IAM Identity Center and Microsoft Entra ID (formerly Azure AD) for Just-in-Time Access (JITA) and Zero Standing Privilege (ZSP) is indeed possible and can be an effective approach. However, as you've noted, scalability and manageability are important considerations.

The method you've described using custom attributes for each role can work but may become difficult to manage at scale. There are alternative approaches that might be more suitable for larger implementations:

1. Group-based approach: Instead of using custom attributes for each role, you can pass group memberships from Entra ID to AWS IAM Identity Center. This can be done by configuring your SAML assertion to include group memberships as attributes. In IAM Identity Center, you can then use these group memberships to make access control decisions.

2. Using existing Entra ID attributes: IAM Identity Center allows you to use employee attributes from any configured identity source, including Entra ID. This means you can leverage existing attributes in your directory for access control decisions, potentially simplifying management.

3. Combining ABAC with role-based access control (RBAC): You can use a hybrid approach where broad permissions are assigned based on roles (RBAC), and then fine-grained permissions are controlled using attributes (ABAC).

Regarding passing an array of group memberships in the SAML assertion, this is indeed possible. You can configure your IdP to pass multiple group memberships as a single multi-valued attribute. In IAM Identity Center, you can then use condition statements like ForAnyValue to check for membership in specific groups.

When implementing this in practice, consider the following:

1. Performance: Evaluate the impact on authentication times, especially if passing large numbers of attributes or group memberships.

2. Attribute synchronization: Ensure that attributes in Entra ID and IAM Identity Center are kept in sync to avoid access issues.

3. Auditing and monitoring: Implement robust logging and monitoring to track access based on attributes, which can be crucial for security and compliance.

4. User experience: Consider how the JITA process will work from the user's perspective, ensuring it's not overly cumbersome.

5. Policy management: Develop a strategy for managing and updating IAM policies that use attributes, as this can become complex in large environments.

6. Testing: Thoroughly test your ABAC implementation across various scenarios to ensure it behaves as expected.

Remember that while ABAC can provide more flexible and fine-grained access control, it also introduces complexity. It's important to balance the benefits of ABAC with the overhead of managing a more complex access control system.

Lastly, consider reaching out to AWS support or consulting with AWS partners who have experience implementing ABAC in similar environments. They may be able to provide tailored advice based on your specific use case and scale.
Sources
Attribute-based access control - AWS IAM Identity Center
Use custom attributes for Attribute-Based Access Control (ABAC) with Microsoft Entra ID and AWS IAM Identity Center | Microsoft Workloads on AWS
AWS IAM Identity Center Features – Amazon Web Services (AWS)
AWS IAM Identity Center - AWS Prescriptive Guidance
Enable and configure attributes for access control - AWS IAM Identity Center