Configuring Iris Approver
This feature is not available in FedRAMP-compliant tenants.
This feature is currently available only to customers participating in a Private Preview. If you'd like to participate and be among the first to try this feature, ask our support or account team for details.
Iris Approver must be enabled initially and then configured with a profile (which provides guidance on approval logic) and then associated with a Secret Server access request workflow. Workflows can involve multiple approvers, including humans and non-humans.
Enable Iris Approver
An administrator with the Platform Admin role can view the Iris Approver page and enable the feature.
-
Navigate to Settings > Iris Approver.
-
Select Edit.
-
Change the State switch to Enabled.
-
Accept the AI usage agreement.
Grant Permissions
An administrator with the Platform Admin role can grant manage and view privileges to users via the following permissions. This role inherits both permissions by default.
-
delinea.platform/irisapprover/manage: Grants a user permission to manage Iris Approver profiles, connectors, and access requests.
-
delinea.platform/irisapprover/view: Grants a user permission to view Iris Approver profiles, connectors, and access requests.
A user needs both Manage and View permissions to administer Iris Approver. The recommended approach is to create two Groups: one with both Manage and View permissions and another with only View permissions. Administrators can then assign users to these groups to grant the appropriate level of access.
See Roles and Permissions to understand how Permissions, Roles, and Groups help implement role-based access control on the platform.
Create a Profile with Authorization Checks
Iris Approver profile configuration helps implement authorization checks (security policy) to assess secret access requests.
-
Navigate to the Iris Approver page. The Configuration tab opens by default.
-
Select Add profile. The Profile pane appears.
-
Choose a name for the profile.
-
Select Recommend or Decide.
-
Select authorization checks to be included in the profile:
-
Choose default checks.
-
Optionally, add one or more custom checks.
-
-
Review the Preview Checklist, which displays the final checklist combining default and custom checks. Information about the applicability, inclusion, special cases, and rationale for each custom check is also provided.
-
Save the profile to return to the Configuration tab.
A service account is created automatically with all required permissions to communicate with the Delinea Platform.
Choose Default Checks
Default (built-in) checks can be included or excluded when assessing a secret request workflow. The following table explains default checks that are currently supported.
| Name | Description | Default state | Source |
|---|---|---|---|
| Check user risk level | Consider the likelihood of user account compromise | Selected | Analytics |
| Check if user used MFA1 | Check if user authenticated with MFA in their recent logins (not supported for federated users1) | Not selected | User audit logs |
| Check request access duration | Validate that the duration the resource is requested for is reasonable and not excessive | Selected | Secret access request |
| Check request justification appropriateness | Validate that the access justification is reasonable, specific, professional and contextually appropriate to the requested resource | Selected | Secret access request |
| Check user justification against ticket(s) | Consider how the requester's stated intent matches with details of the ITSM ticket provided in the secret access request | Conditional2 | ITSM integration via connector(s) |
1 Currently not supported for users that authenticate via external Identity Providers like Entra ID, Okta etc.
2 Selected if an ITSM (Zendesk, ServiceNow) connector is enabled in the tenant. Unselected and disabled if no ITSM connector is enabled in the tenant.
Add One or More Custom Checks (Optional)
Custom checks allow administrators to specify authorization checks in natural language. These checks are optional and can modify or complement the default checks to implement specific security policies. One or more custom checks can be added to a profile.
The Preview Checklist control on the profile configuration screen provides real-time feedback on the applicability and effectiveness of custom checks, and can be reviewed before saving a profile.
Custom checks are an experimental feature. Access request evaluations may produce unexpected results.
| Category | Example | Source(s) |
|---|---|---|
| Modify default check | Approve only if access request duration is >30 minutes | Secret access request |
| Combine default checks | Approve only if FIDO MFA is used if user risk level is high | User audit logs, Analytics |
| Failed login attempts | Do not approve if login failure rate is >75% in the last 3 days | User audit logs (last 30 days) |
| Location anomalies | Deny if location anomalies are detected | Analytics Alerts (last 24 hours) |
| Day of week and time of day | Approve only if access request was submitted Monday through Friday, between 8 A.M. and 5 P.M. US eastern standard time | Secret access request |
| Access request justification text | Approve only if "#ScheduledMaintenance" appears in request justification | Secret access request |
| Secret property | Approve only if secret template is Active Directory Account and a launcher is enabled | Secret Server |
| Secret metadata | Deny if the requesting user account is not present in user metadata field of the secret | Secret Server |
| Ticket status | Approve only if the ticket is "In progress" and has been approved | ITSM system |
| Ticket creator | Deny if the requesting user is the one who created the associated ticket | ITSM system |
| Ticket Configuration Item | Approve only if the configuration item in the ticket matches the application the secret is associated with | ITSM system, Secret Server |
| Override condition | Do not check for any other condition and always approve if secret is classified low risk and user risk level is low or better | Secret Server, Analytics |
Tips for Writing Effective Custom Checks
| Do | Don't |
|---|---|
| Specify if the condition needs to resolve to an "Approve" or "Deny" decision | Use generic statements like "check for location anomalies" or "check for MFA". These will not resolve to a specific result. |
| Specify checks against attributes currently supported. E.g. User risk level; MFA used; Failed login attempts; Ticket details like status, created by, created datetime; Secret access request details like duration, justification text, created by | Use attributes that are not supported. E.g. device security status, malware scan results, user is active on payroll, user completed infosec training |
| Include conditions to check that are specific and objective. E.g. "user risk level is low", "Requester is not the same as creator of the ticket", "Access request is not submitted on a Saturday or Sunday" | Use non-instructive, vague or ambiguous criteria for checks. E.g. "user is trustworthy", "user security is high" |
Assign the Service User to a Workflow
Once the profile is created a service account is created automatically with the same name as the profile to maintain the association between an Iris Approver profile and a workflow. Administrators can add it to an existing workflow or create a new one. The Workflows page is linked at the bottom of the Iris Approver page in a Useful links section. See Workflow Overview for details.
Associate an Iris Approver Profile in Recommend Mode to a Workflow
The best practice is to include the service account associated with an Iris Approver profile as the only approver in Step 1 of the workflow, followed by steps that have human approvers that the recommendation will be sent to.
-
Make sure that the Iris Approver profile intended to be associated with the workflow is configured in Recommend mode.
-
Edit or create a workflow and include the service account created with the same name as the Iris Approver profile as the Approver in Step 1.
-
If the workflow has only one step and more than one approver is included in Step 1 of the workflow, make sure that Number of approvers required is more than 1 to make sure that a human is always in the loop. Otherwise, a recommendation from Iris Approver will be interpreted as a final decision by the workflow.
-
Add or edit the workflow to make sure that there are further steps beyond Step 1 and that they contain human approvers.
-
These approvers will be notified when Iris Approver makes a recommendation to approve or deny access.
Do not include a service account corresponding to an Iris Approver profile configured in Recommend mode as the only approver in the last step of a workflow as a recommendation will be interpreted as a final decision by the workflow.
Associate an Iris Approver Profile in Decide Mode to a Workflow
If your intent is to have the only approval in the workflow to be Iris Approver:
-
Make sure that the Iris Approver profile intended to be associated with the workflow is configured in Decide mode.
-
Edit or create a workflow and make sure that it contains only Step 1 and that the service account associated with the Iris Approver profile is the only approver in the step.
-
An approve or deny decision by Iris Approver on this workflow is final.
Integrating with Your Ticket System
Integration with eTicket or ITSM systems supplies Iris Approver with ticket context (e.g., confirming that a database bug-fix ticket exists for the request).
If your organization does not use a ticket system, administrators must deselect Check for user justification against ticket(s) in the default checks section while configuring a profile. This check, if enabled, always expects a ticket number and justification in the access request and will always result in a deny decision.
Zendesk Integration
To include Zendesk tickets in authorization decisions, from the Delinea Platform:
-
Ensure that you have a suitable account to integrate with Iris Approver:
-
A service account (not user account) and an API key with sufficient permissions are required.
-
Make sure that the service account has Agent or Admin role. Light Agent accounts have limited ticket read access and may result in silent Iris Approver evaluation failure.
-
-
Navigate to the Add Connector page.
-
Select Zendesk as the Type and enter the Display Name, Base Address, API Key, and Email (API user).
-
Select Save.
ServiceNow Integration
To include ServiceNow tickets in authorization decisions, from the Delinea Platform:
-
Ensure that you have a suitable account to integrate with Iris Approver:
-
A service account (not user account) and a password with sufficient permissions are required.
-
Make sure that the service account is assigned the itil role across the ServiceNow implementation, which is required for read access to all ticket table types and otherwise will result in silent Iris Approver evaluation failure.
-
-
Navigate to the Add Connector page.
-
Select ServiceNow as the Type and enter the Display Name, Base Address, User name, and password.
-
Select Save.
Jira Service Management Integration
To include Jira Service Management (JSM) tickets in authorization decisions, from the Delinea Platform:
-
Ensure that you have a suitable account to integrate with Iris Approver:
-
A service account (not user account) and an API key with sufficient permissions are required.
-
Ensure that the service account is added to all JSM projects that you expect Iris Approver to look up tickets in.
-
In classic implementation, make sure that the service account has at minimum the "Service Desk Team" role (or equivalent Browse Projects access) in those projects to avoid silent failure of Iris Approver evaluation.
-
In scoped token implementation, make sure that the API token has
read:servicedesk-request,read:jira-work,read:jira-usergranular permissions to avoid silent failure of Iris Approver evaluations.
-
-
Navigate to the Add Connector page.
-
Select JSM as the Type and enter the Display Name, Base Address, API Key, and Email (API user).
-
Select Save.
Validating Your Configuration
To view, test, and approve access requests, see Viewing Access Requests
Delinea strongly recommends testing each new profile against a variety of scenarios using low-risk secrets.
Administrators may need to adjust the authorization checks for optimal results.