Creating role with OR term for entitlements from different applications

Hi,

We are trying to create Roles that may contain entitlements from multiple applications for the purpose of certification. Currently we only see the OR option for entitlements from the same application. Is there any way to achieve the same with multiple apps?

For example: We have Entitlement A in Application A and Entitlement B in application B
We want to create Role AB such that it will be assigned when an user has either entitlement A or B.
Upon revocation we would like to remove all the entitlements associated with Role AB that the user currently has.

Hi @sonluong,

Try going through this to understand the different types of roles, and their use cases.

https://documentation.sailpoint.com/identityiq/help/rolemgmt/role_types.html

From the requirements posted, I think you will have to create IT roles add entitlements to them(You can have entitlements from different applications within an IT role) and then encapsulate them using a business role(Cannot house entitlements directly) then define assignment criteria for the business role accordingly. This could help ease the user access certification.

However I think you’ll have to create 2 different roles for the requirement you posted since all permissions associated with the role are made available to the user as the role is provisioned.

Go through these links to have a better understanding of Role management in IIQ and RBAC

https://community.sailpoint.com/t5/Technical-White-Papers/Role-Management-in-IdentityIQ/ta-p/77726

Hi @sreeram ,
Thank you for your reply. The approach you mentioned was one of the things I have tried. My setup is like this:

IT Role A: associates with Entitlement A
IT Role B: associates with Entitlement B

Business Role AB:

  • Has IT Role A as Permitted Role
  • Has IT Role B as Permitted Role
  • Has Match List (Role.name = “IT Role A”) OR (Role.name = “IT Role B”)

When the user gets Entitlement A or Entitlement B —> IT Role A or B is Detected —> Business Role AB gets Assigned

The problem we have is when we revoke Business Role AB, the associated IT Role(s) does not get revoked along with it. As I understand, it could only work when the IT Role is a Hard Permitted role, which is explicitly requested as part of a business role request. In the case of Role Detection it is only considered Soft Permitted.

1 Like

Hi @sonluong,

Try changing ITA & ITB as required roles instead of permitted roles. Run a targeted certification to test. This seems to be fetching the expected result for me in my dev env. Please let me know if this worked out for you.

image


1 Like

Hi @sreeram,

Thank you for your suggestion. I have tried this method and even though the role detection and revocation works, there is another problem: If the user only has one of the IT roles, the IIQ will try to provision the other role as well, since they’re specified as Required roles for the business role.
Can we intercept the provisioning plan for certification revocation to modify for our needs?

Hi @sonluong,

Could we split the Business role in 2, as in instead of Business Role AB

Business role A with assignment criteria Match List (Role.name = “IT Role A”) → IT Role A
Business role B with assignment criteria Match List (Role.name = “IT Role B”) → IT Role B

We could always customize, could you elaborate on the customization requirement?

Hi @sreeram,
If we separate the Business role into multiple smaller ones, it would kind of defeat the purpose of creating the business role in the first place (to avoid having too many line items for the certifier)
In terms of customization, would it be possible to intercept the revocation provisioning plan for the Business Role and add the Permitted Roles to the plan as well? That way automated revocation can be achieved with the Permitted Role method.

I think you need to need to look into the requirement and scalability prospective before directly jumping to solution .

to me it seems like some dependency type of requirement that E1 will not work without E2 . one may be for AuthN and other is for AuthZ

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.