Access Entities
Last updated
Last updated
Access Entity records described bundles of one or more Okta applications that a user can request.
Access Entities contain information about the access imparted as well as the behavior of that access.
The Access Entity form is organized into sections to simplify configuration:
Main Form: Basic configuration of the Access Entity
Attestation: Attestation/Certification policies for the Access Entity to ensure access is time-boxed and recertified appropriately
Availability: Determines when Access Entity is requestable by users
Access Approvals (related list): Approval chain and configuration for Access Entity requests
Type: Category for the Access Entity. This is used for labeling & filtering purposes only.
Manually provisioned: If enabled, all approvals and attestation activities will occur, but no auto-provisioning activities will occur in Okta. Instead, a Catalog Task is created and assigned to the selected group for manual provisioning
Group definition: How the Okta groups to be included in the Access Entity are determined
Simple: Choose one or more Okta groups from a pick-list of Access Entities
Scripted: Return an array of Okta Group SysIDs
Track assignment locally: Okta is considered the source-of-truth for assignments. Enabling this will also keep a record of Access Entity assignments locally in ServiceNow. This is used to limit the number of API calls made to Okta.
Ad-hoc removal policy: Determines if an inverse Access Rule is able to remove ad-hoc Access Entity assignment or if ad-hoc assignments remain despite inverse Access Rules.
Attestations, also known as certifications, track the granting of an Access Entity to the user. They can be configured to renew periodically, optionally requiring approvals at reach reattestation.
Create attestion record: Enable or disable attestation functionality
Reattestation period type: Type of duration between renewals of attestation
Simple: Specified number of days, and can be set to auto-renew after that time. If not set to auto-renew, access will be removed at end of the duration.
Granular auto-expiration: Set duration with minute-level granularity. Access will be removed at end of the duration.
Scripted: Return an integer number of days, and can be set to auto-renew after that time. If not set to auto-renew, access will be removed at end of the duration.
Allow start time override: If enabled, an option will be exposed on the Catalog Item to allow specification of when access should be granted. If disabled, access will be granted immediately upon approval.
Allow end time override: If enabled, an option will be exposed on the Catalog Item to allow specification of when access should be removed. If disabled, access will be removed (or renewed) at end of the attestation period.
Availability settings determine when an Access Entity is available for request via Service Catalog.
Apply availability schedule?: When enabled, a schedule can be set such that requests can only be made for the Access Entity within (Inclusive) or outside-of (Exclusive) the specific schedule.
Schedules are only assessed at the time a request is being placed. If a user attempts to request access outside of a schedule, they will be alerted and will be unable to place the order. Delayed approvals may result in access being granted outside of the schedule.
Access Approvals determine the approval chain that is necessary to request, recertify, and remove an Access Entity from a user.
Type: Type of approval
Group: ServiceNow Group
User: ServiceNow User
Requested-for Manager: Manager of the requester
Scripted: Return a GlideRecord of a ServiceNow user
Initial approval: Require approval on initial request for access
Reattestation approval: Require approval on periodic recertification of access
Removal approval: Require approval before removal of access
Order: Approvals will proceed in serial by ascending Order
Conditional approval: Approvals can be conditional. This can be useful if approvals should be skipped for VIP users or users in a particular department, for example.
Simple: Check a filter condition against the requesting user record
Scripted: Return true/false on whether approval should be processed
