Enabling JIRA Tickets for Access Review Removals
Last updated: October 7, 2024
Background
Once you've connected Jira, you may want to set it up so that Lumos creates a ticket for all access removals or access modifications. See📄 Connecting Jira
This article provides a breakdown of how Lumos creates tickets for access review removals/ modifications in Jira and instructions for setting up the ITSM connection.
Setup instructions
1. Go to your ITSM settings.
2. Choose Jira Cloud or Jira Server in the dropdown (choose the one you connected) and click "Connect".
If your Jira is behind a firewall, you may need to allowlist the IP address 44.228.74.159 so that Lumos can communicate with your Jira tenant.
3. Enable Access Removal Tickets.
4. Specify the Project, Request Type, and Resolve With values.
More context on these values can be found below.
Project
The Project maps to your Jira Service Desks. You will not be able to select a Project without valid Request Types (click the Request Type tab for more info on valid Request Types).
Jira API endpoint: https://docs.atlassian.com/jira-servicedesk/REST/4.18.2/#servicedeskapi/servicedesk-getServiceDesks
Request Type
The Request Type shows you the request types for a given Service Desk that:
Have a summary field
Have a description field
Have no other required fields
If a Request Type does not meet these criteria, it cannot be used by Lumos.
Jira API endpoint: https://docs.atlassian.com/jira-servicedesk/REST/4.18.2/#servicedeskapi/servicedesk/{serviceDeskId}/requesttype-getRequestTypes
Deprovisioned/ Resolve with
The following are Lumos statuses that you will map with your ITSM transitions:
Waiting for manual removal: a pending state where a user needs to have their account/permissions removed
Deprovisioned, suspended, webhook removal, and user unassigned from group: a finished Lumos state after a user has been removed.
We recommend a custom workflow where you can set up transitions that are bidirectional between “Waiting for manual removal” and the rest of the Lumos statuses. Then, select those transitions for each Lumos status.
To try each final status (e.g. suspended, deprovisioned), head to an access review. Change one of the apps in the access review to have a Removal Method of Suspended, Deprovisioned, etc.
If you enable Bidirectional syncing, you can move an account or permission from pending to a final state -- and vice versa -- via Jira and Lumos.
Below is an example of a Jira workflow for access review removals:
5. Click "Save" to save your choices.
Supported workflows
The workflows supported by our Jira integration are listed out below, for reference.
Create a ticket for a manual removal task generated by a Lumos Access Review
Lumos creates a ticket in your specific Jira Project and Request Type with the following fields.
Request Type ID: The Request Type you configured in your ITSM settings.
Service Desk ID: The Project you configured in your ITSM settings.
Summary and description shown below:
Log a ticket for any automated deprovisioning done by Lumos for audit trail.
Lumos creates a request in your specified Jira Project and Request Type with the following fields.
Request Type ID: The Request Type you configured in your ITSM settings.
Service Desk ID: The Project you configured in your ITSM settings.
Summary and description shown below:
Resolve the ticket when an access removal is complete
Lumos resolves the ticket using the removal transition from your ITSM settings.
If you're mapping additional Jira statuses to Lumos statuses, we'll choose the status you've mapped if the outcome is not Provisioned (i.e. Canceled).
Jira API endpoint: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-transitions-post
Frequently Asked Questions (FAQs):
When are ITSM tickets created for access removals?
ITSM tickets are only created after an account/permission is removed or is marked as waiting for removal in an access review.
What happens if a project or request type is changed?
If a project or request type changes, we won’t be able to recreate the existing access removal ITSM tickets and the sync between ITSM and Lumos will fail. We will continue to create and sync ITSM tickets with Lumos for access reviews that have finalized the accept/rejection of accounts/permissions.
What happens if a transition is remapped?
If a transition is changed in settings to a different transition type, there is a possibility we are unable to move a ticket between statuses in the customer’s ITSM properly.
If a transition change is made such that the ID is diffe
What happens if a transition is deleted?
Lumos saves transition integer IDs rather than by name. If a transition is deleted in a workflow in the ITSM, the user will need to go to settings, save the Lumos status to a transition of “Not Set”, Save, then set the transition to the new/recreated transition.
Can ITSM tickets be created for existing access reviews that have already marked accounts/permissions as needing removal?
No.
Who is creating and commenting on access removal tickets?
Many customers configure a service account to act on behalf of Lumos. When integrating Lumos with Jira via Lumos's integration tab, you'll likely utilize the service account for logging in. The name of the author of the tickets and comments that Lumos creates is the name of the service account.
Can you reuse transitions?
As of now, transitions can only be utilized once per Lumos status.
Will we create removal tickets for modify access decisions?
Yes, we create tickets for account removals as well as modifying account permissions.