User Add/Change/Delete workflow with permissions scheme?

[Jay Libove]

I am thinking of using JIRA to set up a User account management Add/Change/Delete workflow. It seems likely that someone else has already done this, and either could make it available or could sell the configurations. Has anyone seen this? I looked through the marketplace and didn't come across anything which seemed to include this functionality.

This is a workflow whereby a user, or the user's manager, or any other interested person - as the Reporter - would create an Issue requesting a user Add, Change or Delete action be taken, relating to some account with some privileges on some system.

For example, HR could create an Issue when a new person joins the company saying "(Reporter)HR, on behalf of (define Field here)Employee_Name, requests to Add an account, in the System "Google Apps" with (specific permissions and other characteristics in a Comment field)".

Or a project leader could create an Issue requesting that an existing employee from a resource pool be granted additional privileges on some system, to enable that employee to participate in a new project.

Or a manager could create an Issue advising of the imminent departure of an employee from the company, requesting the suspension of all of the accounts to which that employee has had access.

There would be a workflow which performs a lookup based on the system (Google Apps in this case) to identify the System Owner (a business person who would decide whether to grant the request) and JIRA would forward the created Issue to that System Owner. If the System Owner approves then JIRA would route the Issue onward to (another lookup, the Custodian of the implicated system).

At each stage, specific permissions would apply; for example, when the Issue is first created, it would be readable by only the System Owner contact(s) for the implicated System (and the reporter, and an Auditor role); only the System Owner contact(s) would have permission to change the state of the Issue to allow it to move on, etc.

The goals are an easy to use automated workflow, and security sufficient to creating an auditable trail of request/ approval/ implementation/ closure (or, at any stage, rejection -> closure).

Is this asking for something for which JIRA is well-suited? .. or am I trying to shoehorn this into a great tool that simply may not be the great tool for this specific purpose? I'm not sure, because really one more thing which such a system ought to do is maintain a database of who has what accounts (at a minimum). The workflow and permissions stuff I'm fairly sure JIRA can do, but having the side effect of maintaining a user/system matrix/database does not seem to be JIRA's thing?

And, if this isn't right for JIRA/ there is no prior art in JIRA, I'd appreciate suggestions of tools to do this, without crossing into the full (complicated, expensive, very time intensive to deploy) IAM space.

thanks,

[Renjith Pillai]

JIRA is surely meant for such usecases :)

My suggestion.

• Use components to automatically route the issues to the system owners (the first level)
• add a project role called auditors and add the rights people to that
• Use permission scheme to restrict is to assignee, reporter and project role auditor
• once it reaches the approved phase, present the assignee selection window for the system owner to decide to route the issue to the next assignee (custodian). Or use script runner and write a post function to automatically handle it - https://jamieechlin.atlassian.net/wiki/display/GRV/Script+Runner
• Restrict the workflow conditions again using script runner to restrict it to component leads
• and every action is in history and everything is trackable
• And checkout marketplace and you find there a ton of plugins which gives you a lot of workflow conditions, post functions, validators, custom fields which will help you in many things.

[Jay Libove]

Thanks Renjith. I had been hoping that I would not be re-inventing the wheel, having to develop from zero like this. The simple fact that nobody has apparently done it yet, suggests that although it may be capable, there are reasons why it is not a correct environment.

If nothing else, the need for dynamically adjusted permissions at each state transition would seem to push the limits of JIRA - possible, but probably at the edges of what was envisioned as a normal kind of use.

[Nic Brough -Adaptavist-]

Actually, no, you're not alone - I've done something very similar, although it was a bit more simple. Frankly, most of the tricks I'd scribble are covered by Renjith's post, but we didn't use the script-runner, just a post-function that created users once authorised and another that copied groups from a "group select" field onto a user's profile (I'd probably use the script runner to do that nowadays, but never looked into it enough to see if it could do the sneaky bit of grabbing admin rights over user groups without handing jira-admin rights to the authorisers)

The basic idea was "one issue per user", with authorisers selecting the groups they wanted the users added to (or removed). Slap a load of custom fields on the issues for HR related stuff too, and have a workflow that is something like "New user to be added, User Authorised and active, User has left". Jira's off-the-shelf history tracked everything automatically. We even ended up using it for holiday and sickness tracking, although that was a separate project and they just asked you to link those back to your user id issue.

[Jay Libove]

Hi Nic, thanks for your reply!

You noted "a post-function that created users once authorised" and "another that copied groups from a 'group select' field onto a user's profile".

It sounds like these things relate to JIRA users. Do I understand correctly?

We're not thinking of having the actual user ID/account creations performed by this system; just using this system to run a workflow for requests and authorisations, and create a secured audit log for later review. We plan to use this JIRA-operated workflow-and-auditlog system as the way for ALL accounts in our whole environment to be requested, reviewed, approved, and logged, not just JIRA users and permissions.

Any chance of arranging a demo of what you've got (and maybe a beer-and-pizza exchange for an exports of the workflows, scripts, etc you wrote)?

thanks,
Jay

[Nic Brough -Adaptavist-]

Oh, absolutely, I should have said that the "add/update user's Jira accounts" came after the original "we'd like to track people in the organisation in Jira" - mostly because the Jira admin team got really bored of having PMs chase them when there were requests in the system for Jira access. It was simply logical to invest a couple of days writing add/update user post functions, than carry on spending a day a week doing it manually and being hassled by people.

I'm afraid the stuff I had was written for v3 though, and I've moved on from that client. The workflow was not complex though, really was only three steps. I don't remember the coding being too painful either, post-functions are pretty simple, especially when they have no real configuration.