Configuring Iris Authorization

This Delinea Iris AI feature is currently available only to customers participating in an approved Public 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.

Navigate to Settings > Iris Authorization.
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/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.

Navigate to the Iris Authorization 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.
Associate a service user with the profile:
- Select Managed Service Account to create and associate a service user automatically.
- Select Existing Credentials to associate a previously created service user with the profile.
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.

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 MFA¹	Check if user authenticated with MFA in their recent logins (not supported for federated users¹)	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	Conditional²	ITSM integration via connector(s)

¹ Currently not supported for users that authenticate via external Identity Providers like Entra ID, Okta etc.

² 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"

Associate a Service User with the Profile

Each profile requires a service user to gather the information needed for access request evaluation. A service user is unique to a profile. A service user can be automatically created with necessary permissions (recommended), or an existing one can be added to the profile during configuration.

Managed Service Account (Recommended)

A service user will be automatically created and associated to the profile. This is the recommended option due to the following reasons:

The service user is created with the same display name as the profile, which is needed to identify it as an approver in the workflow (next step).
The authentication certificate is created and managed automatically.

Existing Credentials

An existing service user can be associated with the profile using this option. However, this approach is not recommended due to the following additional requirements:

Permissions necessary to work with Iris Authorization will have to be added manually.
The password associated with the account will have to be maintained.

See Adding Service Users, and make sure that the following permissions are assigned to the account:

delinea.platform/audit/event/read
delinea.platform/identity/admin/read
delinea.platform/administration/users/read
delinea.vault/secretserver/secret/read

Assign the Service User to a Workflow

Once the profile is created and the service user has sufficient permissions, the service user must be assigned to 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.

If the service user is configured to Recommend only, do not place it in the final step of the workflow, since a positive recommendation there actually approves access.

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:

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:

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 tickets in authorization decisions, from the Delinea Platform:

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.