Tracking Jira Access can be Daunting

At Coyote Creek we work with a lot of organizations that have hundreds or thousands of employees, each of whom needs to be granted access to specific systems in order to do their job. Some users need database access, some are using JIRA or Confluence, and so forth. Tracking Jira Access —who provides it, who is responsible for it, who ensures that these permissions are up-to-date—can be a large and daunting task.

Luckily, there is an elegant solution: Use Jira to track it all.

Tracking Jira Access

Although Jira, Atlassian’s project management and issue tracking software, is best known for the way it can transform engineering and software development, it’s actually extremely useful for other things, too. One of these other uses is keeping track of who has access to what on your system.

Getting your Jira access tracking system set up

If you’re struggling to get access tracking under control, here’s how to set it up in Jira:

  1. Create a Jira project. Your entire access tracking system will essentially be one Jira project.
  2. Lock down the security of this Jira project. Determine who can see and do what within the project.
  3. Set up each user as a Jira issue. In Jira, issues don’t have to be things that you would think of as being an “issue,” such as bugs. Issues can also be people, tasks or anything else that you want to track.
  4. Create workflows for different types of tasks. For example, upgrading access, downgrading access and reviewing access will each be set up as issues with their own workflows, including the associated workflow screens, tasks and fields.When setting this type of thing up, I find it convenient to have access requests and access downgrades share the same type of screens. This eliminates the need to have two sets of tables, two sets of fields, etc. Instead, whatever each user is getting or not getting access to is on the same list on the back end.
  5. Integrate security into these workflows. By doing this, all of these tasks can be triaged and linked to the “parent issue,” which is the end user. With all access-related requests linked to that person, auditing each person’s access to the system over time becomes a relatively simple matter.

Monitoring Jira access

Once you have your system set up, I recommend you use one of the following two ways to monitor it:

  • Use JQL statements and alerts – With this method you write JQL statements that search for the particular custom fields or flags that you want to monitor, and set it so that the results of these searches are automatically sent to you.For example, I am currently working on a project for a large organization that has a rule in place stating that system access for over 10,000 employees (i.e. those who are in certain categories) must be re-evaluated every three months. To make this happen I first used Jira’s miscellaneous custom fields, which is a handy free add-on, to create a time stamp every time a manager clicks the button that enables a user to gain or continue to have access. I also simplified their workflow by creating separate issue types that all link into one approval process. With these things in place I then created a JQL statement that searches for issues with time stamps that are close to three months old and notifies the appropriate managers that the re-evaluations need to take place.As this example demonstrates, JIRA workflows can interact with other Jira workflows. The approval process can be linked into the issue type, even though approvals and issues types are separate workflows. With the way I set things up for this client, the workflow is that the issue gets opened, goes through the approval process and is then either confirmed or denied. If it is denied the issue gets closed. If it is approved it goes through a process to be enacted. Security, notifications and flags are all built into this one workflow.
  • Use Confluence as an interface for the project – Another monitoring option is to link a Confluence space to your newly created tracking Jira access project, and then build that Confluence space as the security and monitoring interface for that team. For this approach pull all of the appropriate metrics into that Confluence space, such as charts, graphs, the results of your JQL searches, and more. For easy visualization of the data I recommend using the eazyBI reporting system (see my previous article on 7 Reasons Why I Love eazyBI) and embedding eazyBI reports in your Confluence space.

Conclusion

Many larger organizations really need an access tracking system like this for tracking JIRA access, or other programs. JIRA already has the proven tools to make it happen, complete with security to ensure that only the appropriate people have decision-making authority within the JIRA project. There’s no need to reinvent the wheel—just build it and use it!

Plus, as an added bonus, with JIRA, JQL subscriptions or dashboards can be used to notify managers. This can help you steer away from using email, which is a very inefficient way to work as a team. Instead of having to search through your email history to try to figure out the history behind a user’s access, you will be able to simply go straight to the JIRA issue (i.e. the user) and quickly pull up the details of their full history.

Need help putting a system like this in place, or implementing Atlassian tools for any other purpose? Give us a call. As Atlassian Platinum Solution Partners, we have the expertise you need.