Identity & Access Request Workflows using Jira
How to use Jira’s customisable workflow engine to setup your Identity & Access Request workflows
Background
As a licensed digital Peer-to-Peer Lending platform in South East Asia, Funding Societies | Modalku Group is subject to several regulatory requirements.
One such requirement relates to the critical security domain of Identity & Access Management (IAM). As per Gartner:
IAM is the discipline that enables the right individuals to access the right resources at the right times for the right reasons.
Three fundamental IAM principles for protecting information systems (or simply, systems) are:
- Never alone principle: Some system functions and procedures may be so critical and sensitive that they should be carried out by more than one person simultaneously, or performed by one person and checked by another.
- Segregation of duties principle: Responsibilities and duties (such as access control administration; systems design and development; operating systems functions; etc.) should be separated and performed by different groups of employees. Job rotation and cross-training for security administration functions should also be established.
- Access control principle: Access rights and system privileges should be based only on job responsibility and the need for users to have them in order to fulfil their duties, and not based on users’ rank or position.
With these principles in mind, as a FinTech operating on a controlled budget having to comply with regulatory requirements, our challenge was to come up with a cost-effective solution for allowing users to access systems only on a need-to-use basis and within the period when the access is required in an auditable manner.
Our Approach
We were able to address the challenge by firstly, coming up with the Identity & Access Request Process flow below, which ensures that two individuals — viz. the user’s line manager and the system owner — have duly authorised and approved a user’s request to access a system:
- While the line manager is the individual responsible for managing the user to achieve specific functional or organisational goals,
- The system owner is a role adapted from the National Institute of Standards and Technology’s (NIST) definition of an individual responsible for the procurement, development, integration, modification, operation, maintenance, and/or final disposition of a system.
Depending on how departments / teams are organised, the owner of a system could either be an individual having any of the aforementioned responsibilities for the system, or an individual who holds the owner account for the system (e.g., in the case of a Software as a Service (SaaS) subscription).
The roles and responsibilities of stakeholders in the process are as follows:
Secondly, we leveraged Atlassian’s Jira, which was already being extensively used in the company for issue tracking and project management (hence, no additional cost!), to implement the Identity & Access Request workflows.
Solution Implementation in Jira
A new Jira Software project was setup and configured with a new issue type to capture access requests pertaining to:
- User Account Provisioning, when there is a need to register and grant access rights for new users of a system.
- User Account Modification, when there is a need to change and update existing user access rights in a system.
- User Account De-provisioning, when there is a need to revoke access rights of users, who do not need to access to a system anymore.
Custom fields were created, such as User(s) for whom Access is Required; Type of Access Request; System to which Access is Required; etc., and the create access request screen was defined as per the image below:
In addition to the fields that can be seen above, the access request form also has some additional custom fields for systems that require them, such as the Duration after which the Requested Access can be Automatically Revoked; Roles for which Access is Required; etc.
The System to which Access is Required custom field is the golden source of all systems used in the company.
For each system, the list of primary and delegate system owners, as well as primary and delegate ticket assignees, are being maintained using user groups. This is to allow the delegate system owners / ticket assignees to take the required action on the access request in case the primary system owner / ticket assignee is unavailable.
Upon creation of an access request by a user:
- An integration, which has been developed internally with the company’s HR platform using Jira REST API, will automatically fetch and populate the user’s line manager details in the access request.
- Automation rules comprising of triggers, conditions, and actions, which have been configured in Jira, will automatically assign the access request to the respective system owner & delegate(s) and ticket assignee & delegate(s) as per the image below:
Next, a workflow using statuses and transitions was created to mirror the Identity & Access Request Process:
1. When a user submits an access request, it gets created in the BACKLOG status.
2. An automation rule checks that the values for the user’s line manager, system owner and ticket assignee are not empty, and automatically transitions the access request to the PENDING LINE MANAGER’S APPROVAL status:
Additionally, another automation rule notifies the user’s line manager that the access request is pending his/her approval by adding a comment in the request itself as well as by sending an email to him/her:
3a. If the user’s line manager decides to reject the access request, it moves to the REJECTED status. (NOTE: A condition has been added to the Reject transition to ensure that only the user’s line manager, and nobody else, can reject the access request.)
3b. If the user’s line manager approves the access request, it moves to the PENDING SYSTEM OWNER’S APPROVAL status. The same condition as in the above step has been added to the Approve transition.
Once the user’s line manager has approved the access request, an automation rule notifies the system owner that the access request is pending his/her approval by adding a comment in the request itself as well as by sending an email to him/her.
4. The Approve and Reject transitions going out from the PENDING SYSTEM OWNER’S APPROVAL status have been configured with a condition that they can be carried out either by the primary or delegate system owner(s) only, and by nobody else:
If the primary or delegate system owner(s) decide to:
- Reject the access request, it moves to the REJECTED status.
- Approve the access request, it moves to the IN PROGRESS status and Jira automatically notifies the primary ticket assignee about the same.
5. Here again, the Done transition going out from the IN PROGRESS status has been configured with a condition that it can be carried out either by the primary or delegate ticket assignee(s) only, and by nobody else. This transition will move the access request into the DONE status.
6. For an access request that is in the REJECTED status, if either the user who raised the access request and/or the user(s) for whom the access has been requested would like to resubmit the access request (perhaps, after modifying some information in it), they can execute the REOPEN transition to move the access request back into the BACKLOG status, which would kick off the workflow from start again.
Lastly, a Kanban board was set up, with the columns corresponding to the statuses of access requests, to easily visualise and manage them:
Filters can also be added to the board to easily view a required set of access requests, for e.g. the logged-in user’s Requests to Approve as SysOwner or Requests Assigned to him/her:
Summary of Jira Features Utilised
For quick reference, here is a round-up of all the Jira features that have made the Identity & Access Request Workflows possible:
Benefits
Since the Identity & Access Request Workflows were set up in Jira, the process has been diligently followed across the company.
Importantly, we have been able to not only successfully replace other means of access requests that could not be audited / monitored / reported on (such as Slack channels, Google Forms, etc.), but have also been able to achieve wider productivity gains such as:
- Automating all access requests to all systems across the company.
- Save a lot of productive time for all the stakeholders involved:
- People who are requesting for access
- People who are approving the access (Line Managers and System Owners)
- People who are provisioning it (IT Team and/or System Owner/Team)
- People who are auditing (Security and Compliance teams)
Finally, as it only takes a few minutes to add / modify / remove a system and/or system owner information in Jira, it is very easy to manage and scale the access request system with the needs of the company.
Thank you for reading this post! I hope that this will help you in setting up your Identity & Access Request workflows and/or other such workflows using Jira’s customisable workflow engine with ease. Do let me know your thoughts / suggestions in the Responses section below.
