This article looks at how to use Jira to raise and manage time-bound privileged access requests in Okta Privileged Access. It leverages an Okta Workflows solution that integrates with Jira and then manages Okta group membership.
Introduction
Before looking at the solution details and the user flows, it’s worthwhile providing an overview and some design considerations.
Overview of the Solution
The solution is implemented in Okta Workflows, with integrations into Jira, Okta and email.
The following figure shows the main components and interactions.
Starting on the right of the diagram, there is Okta Privileged Access (Okta PA or just OPA). It has policies that control who (via groups) can access which resources (e.g. servers) and how (different accounts and controls). It’s important to note that this is controlled at the group level in OPA, not the individual. These groups are normally pushed from Okta (WIC).
In Okta the Okta PA application has push groups assigned. Whenever these groups are changed in Okta, the updated group is pushed to Okta PA which affects who is subject to the OPA policies. Thus you can have different groups in Okta to represent different access roles in OPA assigned to different policies.
Whilst these groups could be managed in Okta itself by an admin, via APIs or via Access Requests in Okta Identity Governance, we want to be able to manage them from within Jira. To do this we have implemented a series of Okta Workflows to respond to tasks raised in Jira. These tasks could be to request (create) privileged access, extend privileged access or view the current privileged access.
Within the Workflows solution there is a table to keep track of requests (and one for an audit trail, not shown) and a series of workflows:
- A workflow to create a new request, which will add the request to the requests table and add the user to the group in Okta.
- A workflow to extend an existing request, which will update the expiry time on the request in the requests table (but not change the group membership)
- A workflow to view the existing requests for a user, including the expiry times for each
- A workflow to periodically check for pending (soon-to-expire) requests and notify the user
- A workflow to periodically check for expired requests and remove the user from the relevant group
The first three are triggered on a new task being created in Jira. The last two run on a timer to periodically check for soon-to-expire and expired requests. All workflows will result in emails being sent to the user.
Some Design Considerations
It is a common ask for service delivery or ticketing tool to be able to raise requests against Okta resources (apps, groups and entitlements) using Okta Identity Governance and its Access Requests feature. This involves the tool, like Jira, to make API calls into Access Requests to raise a request. For this solution, we chose to bypass Access Requests and build the mechanism into Okta Workflows directly. This means no OIG license is needed (only Workflows) and there is greater control over the timer functionality.
Okta Workflows has a Jira connector that includes actions such as listening to new issues raised in Jira. Jira has the flexibility of adding custom fields to an issue type. Thus we were able to add an Access type (New access, Extend access, View access) and Admin group (the Okta group the user is requesting access to). These are passed into the workflow using the connector and used for routing and assigment.
A key component of this solution is that access to OPA resources is time-bound. Users are added to a group and an end-time calculated (and when that end-time arrives, access is removed). This time could be fixed or calculated based on the request information. In this case we have used the Change type field: Emergency = 4 hours, Standard/Normal = 12 hours. This is purely arbitrary. You could base this off the Change risk (higher risk = shorter time) or even the group being given access to (e.g. prod group = 4 hours, non-prod = 12 hours). You could use the standard Jira start and end dates. You could even get the user to select a period and pass it into the workflow. This is just to show how it could be done.
The mechanism doesn’t do any vetting or approval. In a real deployment, this would be done in Jira prior to the Workflows getting involved. We have just assumed this is done for the sake of simplicity.
Many of the workflows are bare-bones to show how the solution can be implemented. This includes some back HTML-formatted emails being sent. You could improve them or swap them out for Slack/Teams notifications via the connectors available in Workflows.
The persistent store for both the requests and the audit trail is in Workflows tables. These are not designed for scale or performance, so if you were implementing a solution based on this, you should look at some other persistent store (like an AWS-hosted DB accessed via Lambda functions).
The solution could close out the Jira task when each request is complete, but this was not implemented in the workflows. This could be done by the Transition issue card.
One last consideration, any user requesting access to one of the groups pushed to OPA still needs to be assigned to the OPA application in Okta. This could be done by also mapping the push groups as assignments to the app, having a group assigned for anyone who may need OPA access, or dynamically adding them to an assignment group at the same time as adding them to the push group.
User Experience and Background Flows
Lets walk through the flows from an end-user experience. We have a user, Neville Newadmin (neville.newadmin@atko.email) who is defined in Okta and Jira and needs to perform some urgent maintenance work in some Linux servers.
User Requests Privileged Access
Neville raises a request in Jira request selecting the project and type (Task) and providing a summary and description.
He sets the standard change type, risk and reason fields. The access type is New access as he is raising a request for some new privileged access. He selects the admin group for the request, which is the Okta PAM Linux Sysadmins group (which is assigned to policies in Okta Privileged Access to grant access to Linux servers). He sets a start and end date and team and submits.
Note that not all of this information is needed for the workflows solution, but would form part of the task history in Jira.
Neville checks his email and sees there’s a new email titled Privileged Access Granted.
Opening the email he sees notification that his access has been granted to the Okta group, with the start and end dates of the access.
The access was granted for four hours because it was set to an Emergency type access.
Checking Nevilles profile in Okta, we can see he’s been added to the PAM Linux Sysadmins group as requested.
You may notice that the PAM groups shown contain additional information about the access granted by the group membership. For more information on this see Okta Privileged Access and Access Certification – Getting Roles into the Group Description.
Looking at the Okta system log, you can see that the user was added to the group and that group was immediately pushed to Okta Privileged Access.
This means Neville can access the Linux servers via Okta Privileged Access.
User is Reminded about Pending Expiry of Access
There is a background task (workflow) that is periodically checking for upcoming acess expiration. Neville notices a new email indicating his Linux access will expire soon.
This hasn’t removed any access, it is just checking for access due to expire soon.
User Checks Their Privileged Access
To confirm, Neville raises another Jira task to view his access.
Most of the information here is not important (we just simplified things by reusing the one task template). The access type of View access will trigger a check of Nevilles access.
He receives an email titled All Access Requests.
The email shows that he has three access requests, one completed (DONE) and two that are active – one for his urgent Linux request and a longer (lower risk) Windows server access request.
User Extends Privileged Access
He decides he needs to extend his Linux access as he needs more time for the maintenance task. He enters the same details as for the initial request, but selects an access type of Extend access.
He receives an email indicating his access has been extended with the new expiry date and time.
Note that there has been no change to his access in Okta or Okta Privileged Access.
Privileged Access Expires and is Removed
There is a background task (workflow) that is periodically checking for expired access and if it finds any it removes the access. Neville notices a new email indicating his Linux access has expired.
Checking the Okta system log, we can see that the group membership was removed and pushed to Okta Privileged Access.
Checking Neville’s profile in Okta, you can see he has lost the PAM Linux Sysadmins group membership.
This Neville can no longer perform privileged administration functions on those Linux servers (unless he requests access again).
Details of the Solution
This section of the article looks at how the solution is built. It won’t go into fine details of all the components.
JIRA
The standard Jira task template was modified to add two new Context fields – Access type and Admin group. A set of standard fields were also kept, but only the Change type field is used by the workflows.
The Access type is a pulldown field with three fixed values – New access, Extend access and View access. The workflows are expecting these options exactly as they are.
The Admin group field is a pulldown field with the list being the (exact) group names for the Okta push groups on the Okta Privileged Access application. In this example we have two, one to represent Linux sysasdmin access and another to represent Windows sysadmin access (both tied to specific policies in Okta Privileged Access).
The only other change to Jira was to setup an API token for a user to use in the Workflows connector.
Okta Workflows Connectors
The solution uses three Okta Workflows connectors:
- The Jira Connector – to listen for new issues being raised in Jira and lookup user details
- The Okta Connector – to lookup users/groups, and update group memberships, and
- The GMail Connector – for sending emails (you could replace this with another email connector)
These need to be setup prior to importing and using the solution.
Okta Workflows Tables
The heart of the solution is the persistent store of requests. This Access List table stores:
- The Okta ID of the user
- The Okta username (e.g. first last)
- The user email (their username in Okta and email in Jira)
- The Okta ID of the group being assigned
- The name of the Okta group
- The access start date-time
- The access end date-time
- The status – one of NEW (new active request), EXTENDED (extended active request) and DONE (expired/completed request)
- The access end time in human-readible format in the timezone of the request
This table is accessed by all of the workflows.
The second table, Audit Trail, is a running log of all request updates (add, extend and remove).
This table is written to, but not read. You could export it to CSV for reporting.
Okta Workflows Main Flows
There are eight main flows used in the solution.
The A** flows are used for all three task types coming from Jira:
- The A00 flow is listening for the new Jira task. It will check it’s the type of issue we’re looking for then call one of A10, A20 or A30 depending on whether this is a new, extend or view request.
- The A10 flow will collect the relevant details from the Jira task, find the user and group in Okta, assign the user to the group, add a record to the Access List table and write an audit record out, then send an email to the user.
- The A20 flow will collect the relevant details from the Jira task, find the matching record in the Access List table and update it for the new end date-time (and write an audit record), and send an email to the user.
- The A30 flow will lookup this users records in the Access List table, format them and send an email with the results
The B** flows are for checking for upcoming expirations and notifying the user(s). This would be scheduled to run on a timer, with the frequency dictated by how soon before you want to check and notify. For example, you could run it every hour and check forward an hour, or run it every 15 minutes and check forward for 15 minutes (the sample is set at four hours). There are two flows:
- The B00 flow will search the Access List table for any active (i.e. not “Done”) requests that have an end date-time in the next X period. For each found it calls B01.
- The B01 flow will format and send an email with the results and send an email to the user.
The C** flows are for expiring access and notifying users. This would also be run on a timer and the frequency would be dictated by how soon you need access taken away after an expiry. There are two flows:
- The C00 flow will search the Access List table for any active (i.e. no “Done”) requests where the end date-time has passed. For each found it will call C01.
- The C01 flow will remove the user from the group, update the Access List table (and add an audit record), and send the user an email with confirmation.
These flows all leverage other helper flows.
Okta Workflows Other Flows
There are two sets of other flows involved in the solution – the flows that interact with the two tables (Access List and Audit Trail), and some utility flows.
The T** flows interact with the tables:
- The T10 flow will write a new request into the Access List table and write an entry to the Audit Trail table
- The T20 flow will update a request in the Access List table to indicate the new end time and write an entry to the Audit Trail table
- The T30 flow will read all records in the Access List table for a specific user, and using T31 on each returned record, format the list into a HTML table for use in an email
- The T40 flow will update a request in the Access List table to mark it as “DONE” and write an entry to the Audit Trail table
Finally there are two utility flows called from other flows:
- The U10 flow will find the user in Jira and Okta and return the various Ids for the user
- The U20 flow will do some time calculations to determine end times
This concludes the exploration of the solution components.
Conclusion
It is common to integrate service desk/ticketing tools with Okta. One approach is to use Okta Identity Governance, particularly the Access Requests module. However it may be simpler to tie the service desk/ticketing tool directly into Okta (WIC) and manage apps/groups/entitlements there and ignore OIG completely.
This article has shown how Jira can be used for time-bound privileged access in Okta Privileged Access, leveraging Okta Workflows with the Jira/Okta connectors, and Okta groups pushed to the Okta Privileged Access app and assigned to policies there. We have looked at how you can implement mechanisms to raise requests, extend the time of access, view access and automatically expire access after the allotted time.
Download Sample
The sample workflows used in this article can be downloaded here:
