Configuring Iris Authorization

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 Authorization 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 Authorization

An administrator with the Platform Admin role can view the Iris Authorization page and enable the feature.

  1. Navigate to Settings > Iris Authorization.

  2. Select Edit.

  3. Change the State switch to Enabled.

  4. 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/irisauthorization/manage: Grants a user permission to manage Iris Authorization profiles, connectors, and access requests.

  • delinea.platform/irisauthorization/view: Grants a user permission to view Iris Authorization profiles, connectors, and access requests.

A user needs both Manage and View permissions to administer Iris Authorization. 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 Authorization profile configuration helps implement authorization checks (security policy) to assess secret access requests.

  1. Navigate to the Iris Authorization page. The Configuration tab opens by default.

  2. Select Add profile. The Profile pane appears.

  3. Choose a name for the profile.

  4. Select Recommend or Decide.

  5. Select authorization checks to be included in the profile:

    • Choose default checks.

    • Optionally, add one or more custom checks.

  6. 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.

  7. 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. If this happens, use AI Agent Feedback (thumbs up or flag) and comments on the evaluation result page to help improve the effectiveness of custom checks over time.

Category Example Source(s)
Modify default check Check for access request duration only if it is >30 minutes Secret access request
Combine default checks Check for FIDO MFA if user risk level is high or critical 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 Check for location anomalies Analytics Alerts (last 24 hours)
Day of week and time of day Check to ensure that the 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 Check for "#ScheduledMaintenance" in request justification Secret access request
Secret property Allow access only if secret template is Active Directory Account and RDP is enabled Secret Server
Secret metadata Check to make sure that user exists 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 Check to make sure that the requester is not the same as the one that created the ticket ITSM system
Ticket Configuration Item Check to make sure that 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 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 Authorization 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 Authorization page in a Useful links section. See Workflow Overview for details.

Associate an Iris Authorization Profile in Recommend Mode to a Workflow

The best practice is to include the service account associated with an Iris Authorization 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.

  1. Make sure that the Iris Authorization profile intended to be associated with the workflow is configured in Recommend mode.

  2. Edit or create a workflow and include the service account created with the same name as the Iris Authorization profile as the Approver in Step 1.

  3. 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 Authorization will be interpreted as a final decision by the workflow.

  4. Add or edit the workflow to make sure that there are further steps beyond Step 1 and that they contain human approvers.

  5. These approvers will be notified when Iris Authorization makes a recommendation to approve or deny access.

Do not include a service account corresponding to an Iris Authorization 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 Authorization Profile in Decide Mode to a Workflow

If your intent is to have the only approval in the workflow to be Iris Authorization:

  1. Make sure that the Iris Authorization profile intended to be associated with the workflow is configured in Decide mode.

  2. Edit or create a workflow and make sure that it contains only Step 1 and that the service account associated the Iris Authorization profile is the only approver in the step.

  3. An approve or deny decision by Iris Authorization on this workflow is final.

Integrating with Your Ticket System

Integration with eTicket or ITSM systems supplies Iris Authorization 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:

  1. Ensure that you have a suitable account to integrate with Iris Authorization:

    1. A service account (not user account) and an API key with sufficient permissions are required.

    2. 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 Authorization evaluation failure.

  2. Navigate to the Add Connector page.

  3. Select Zendesk as the Type and enter the Display Name, Base Address, API Key, and Email (API user).

  4. Select Save.

ServiceNow Integration

To include ServiceNow tickets in authorization decisions, from the Delinea Platform:

  1. Ensure that you have a suitable account to integrate with Iris Authorization:

    1. A service account (not user account) and a password with sufficient permissions are required.

    2. 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 Authorization evaluation failure.

  2. Navigate to the Add Connector page.

  3. Select ServiceNow as the Type and enter the Display Name, Base Address, User name, and password.

  4. Select Save.

Jira Service Management Integration

To include Jira Service Management (JSM) tickets in authorization decisions, from the Delinea Platform:

  1. Ensure that you have a suitable account to integrate with Iris Authorization:

    1. A service account (not user account) and an API key with sufficient permissions are required.

    2. Ensure that the service account is added to all JSM projects that you expect Iris Authorization to look up tickets in.

    3. 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 Authorization evaluation.

    4. In scoped token implementation, make sure that the API token has read:servicedesk-request, read:jira-work, read:jira-user granular permissions to avoid silent failure of Iris Authorization evaluations.

  2. Navigate to the Add Connector page.

  3. Select JSM as the Type and enter the Display Name, Base Address, API Key, and Email (API user).

  4. 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.