Automated Deprovisioning

Scheduled expiration dates for access removal based on employment or contract end date that trigger Action Flows for deprovisioming IAM users or roles.

Deprovisioning uses the same ActionChain, ActionChainScript, ActionFlow, and ActionFlowScript that access provisioning uses. You can read more about how this works and the different ActionChainScript types in the access provisioning documentation.

While access provisioning is based on obtaining approval using an ApprovalFlow, access deprovisioning is based on the expiration date (expires_at) of an approvable relationship that has been attached to an AuthUser.

The expires_at value can be calculated automatically when a user is granted access, or can be set later when it is determined that the user no longer needs access.

Approval Policy Calculated Expiration

You should use expires_* values when you want access to automatically be deprovisioned on a scheduled date without any human intervention.

Each ApprovalPolicy allows you to optionally set an expires_after_count (int) and expires_after_period (enum:minute|hour|day|week|month|quarter|year). If a value is set, the expiration date is calculated from the time that the ActionFlow is created after the ApprovalFlow is complete and stored in the expires_at field on the approvable relationship many-to-many record for the user.

If an ApprovalChain has multiple ApprovalPolicies and more than one policy has a value, then the shortest time period value is used for the expires_at calculated value. For example, if two policies exist and one is set for 90 days and the other is set for 12 months, the expires_at value will be calculated as now()->addDays(90).

Access Review Deprovisioning

You should use audit_* values when you want to have the user's access manually reviewed by the AuthUser or AuthGroup that approved their access based on the ApprovalPolicy, and allow the approver to choose whether to extend their access or expire their access at predetermined time period intervals.

See the access review documentation to learn more.

Manual Deprovisioning

If any approvable relationship (usually a user) needs to be deprovisioned, this can be performed using the Web UI, CLI, or API by any of the following:

  • An AuthUser specified in one of the ApprovalPolicy(s) that the user was granted access with.
  • A manager (not a member) of an AuthGroup specified in one of the ApprovalPolicy(s) that the user was granted access with.
  • The user's immediate manager.
  • Any manager in the reporting chain for the immediate manager (ex. Manager > Director > Sr Director > VP > CxO)
  • A user in Access Manager with permissions to perform deprovisioning for the SaaS Provider (ex. System Owner)
  • A user in Access Manager with permissions to perform global deprovisioning (ex. Security Incident Response Team Engineer, IT System Administrator)
  • A superadministrator in Access Manager

Offboarding Deprovisioning

If an AuthUser should have all access removed on a specified day and time (ex. termination or resignation), the expires_at value should be set in the AuthUser model. This value can be automatically updated using an AuthProviderField which maps the field from Okta which inherits data from the HRIS.

A background job checks if the AuthUser expires_at value has been set (not null) and if the value is in the past (ex. 1 minute after), then the background job will loop through all approvable relationships and set the expires_at value with now() so that deprovisioning will start 1 minute later for all of the relationships. The background job interval can be configured to run every minute, however this may be changed to a longer period of time (ex. every 10 minutes, every hour, every 6 hours, or every day) during performance tuning after Access Manager is implemented.

See the offboarding workflow documentation to learn more.

Extending Access before Expiration

An AuthUser can use the Renew Approval button to create a new ApprovalFlow based on the applicable ApprovalChain. After the ApprovalFlow has been completed, the expires_at date will be updated for the approvable relationship record.

The AuthUser will receive an automated notification before their access expires that includes an action button to start the Renew Approval process seamlessly for improved user experience and convenience. The notification for renewal will vary based on the expires_after_* values and can be customized in the Access Manager global settings.

Since the expires_at date is calculated based on the ApprovalPolicy, we want to avoid manually updating the value that can only be done by Access Manager users with elevated permissions.

Renew Approval after Expiration

After the expires_at date has passed, the deprovisioning ActionChain will start and the ActionChainScripts background jobs will automatically deprovision the approvable relationships (ex. users).

You can still request access with a new approval request, however it will be a fresh relationships and/or credentials and may not be not be associated with your old access depending on the SaaS Provider.