Eligibility

The critical aspect of providing a simple end-user experience for access requests and ensuring compliant access is controlling which items different types of users see and may request. Suppose all end users are presented with the same catalog of requestable items. In that case, the user experience quickly becomes overwhelming and confusing as users must filter through large amounts of data to find the access they are looking for that would be relevant for them to request. Exposing unnecessary data also creates a severe security vulnerability as external users or potentially malicious actors may browse the entire catalog of the organization’s most sensitive roles and resources. Also crucial for regulatory compliance is having the ability to blacklist or explicitly deny the ability of certain groups of users to see or request specific roles and resources to enforce country-specific restrictions such as the International Traffic in Arms Regulations (ITAR).

EmpowerID offers a powerful policy engine to control which users may see and request which roles and resources in the IT Shop. These policies are known as “Eligibility.” Eligibility policies may apply to users by attribute query, role, group, or other criteria, making it easy to target who receives which policies and have the assignment automated and maintained throughout their lifecycle. To further ease the administrative burden, Eligibility policies can be applied to all requestable items of a type by location in addition to one by one. This allows policies to be broader granting or excluding eligibility using the EmpowerID Location tree. For roles, eligibility policies can be applied to their members to control what they may see and request in the IT Shop. Policies also apply to the role itself as a possible IT Shop item to control who may see and request it.

Eligibility policies can be defined as either inclusion rules or also exclusion rules. Inclusion rules define the items a user is authorized to see and request in the IT Shop and ensure these are only the ones that would make sense for them to request. A multinational company example would be a Field Sales employee in Austria that should not see the same requestable items as a Developer in Brazil. Their catalog of requestable roles and resources should be different to provide a pleasant user experience and ensure unwarranted access requests are not generated, creating unnecessary approval tasks.

Eligibility Exclusion rules would be created as a protective measure to enforce regulatory restrictions and ensure that specific classes of users are not accidentally given the ability to request items they should not.

Eligibility policy being applied to a Person

Eligibility policies also include the capability of affecting the approval flow for an item requested by a user. When assigning eligibility policies, the policy author may assign an Eligibility Type for the assignment.

There are three types of eligibility in EmpowerID.

  • Eligible – Users can request items in the IT Shop, and the request will go for approval unless the requesting person has the RBAC delegations needed to grant the requested access.

  • Pre-Approved – Users assigned the policies are pre-approved for the items to which the policy is applicable. When the IT Shop user later requests access, it will not require an approval step before being fulfilled.

  • Suggested – The IT Shop item will show a “Suggested” additional item they may request because of their existing roles or in the context of a role they are currently requesting. The item will still follow standard approval routing rules.

 

 

Related Docs Topics:

https://dotnetworkflow.jira.com/wiki/pages/createpage.action?spaceKey=EAGV21&title=Eligibility%20Policies