- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Prevent non-Requestable Entitlements and Apps from Being Added to a Role
We are on 7.1.1 P05 HF01.
We would like to prevent Roles from containing Entitlements which 1) Belong to an Application that has Exclude Entire Application From Add Access And Suggestions set to "Yes" or 2) The Entitlement itself has Available for Request set to "No".
The only way we can see to do this is to have an Entitlement Rule created on the Role Set. Unfortunately, the available Columns do not include either of the two mentioned above...which is simply astounding to me. We tried using the "Advanced" option to create criteria to exclude the non-Requestable Entitlements but again, there is no way to uniquely identify an Entitlement from the available columns.
This is the SQL that we used as a model for the criteria, but as I said there is no column available to uniquely identify the Entitlement (such as ID):
select uents.ID
from avuser.V_ALL_UNIFIED_ENTITLEMENTS uents where uents.EXCLUDE_FROM_NORMAL_ADD_ACCESS = 'N' and uents.CANREQUEST = '1'
Has anyone else successfully excluded non-Requestable Entitlements from being added to a Role?
Thank you in advance.
- Tags:
- Community Thread
- Discussion
- Forum Thread
- Identity G&L
- Identity Governance & Lifecycle
- IG&L
- IGL
- Role Management
- RSA Identity
- RSA Identity G&L
- RSA Identity Governance & Lifecycle
- RSA Identity Governance and Lifecycle
- RSA IGL
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hey I actually used your exact SQL query in-lab and it worked for me. The advanced options doesn't have an "ID” attribute to pick, but it does work when you manually type in ID.
unifiedents.ID in (
select uents.ID
from avuser.V_ALL_UNIFIED_ENTITLEMENTS uents where uents.EXCLUDE_FROM_NORMAL_ADD_ACCESS = 'N' and uents.CANREQUEST = '1'
)
Give it a try on your side and let me know if it works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I can confirm at this time these columns are not available from the Entitlement Rule. As far as I was able to determine you are the first person to request this feature and it is not already posted in RSA Ideas.
This is similar to this discussion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
As you noted this cannot be done with an Entitlement Rule on a Role set, you have already established that and you quoted why it would not work.
Does anyone else have any completely different ideas?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Can you explain why these and other Entitlement columns are not available? I have run into this dozens of times and it is a frustrating aspect of IGL. I can see the columns on tables but they are not available in the UI. Very poor design.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hey I actually used your exact SQL query in-lab and it worked for me. The advanced options doesn't have an "ID” attribute to pick, but it does work when you manually type in ID.
unifiedents.ID in (
select uents.ID
from avuser.V_ALL_UNIFIED_ENTITLEMENTS uents where uents.EXCLUDE_FROM_NORMAL_ADD_ACCESS = 'N' and uents.CANREQUEST = '1'
)
Give it a try on your side and let me know if it works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Hi Mostafa, thank you!! Your suggestion is very helpful!!!
I tested this out quickly in our non-Prod environment and it seems to work great! I tested it both with an Application that has EXCLUDE_FROM_NORMAL_ADD_ACCESS = 'Y' as well as an Application that that has it set to 'N' but the uents.CANREQUEST = '0' and it seems to exclude both scenarios. This is fantastic news for us and I appreciate you taking the time to understand the issue we faced and coming up with a fix!
