Industry Best Practice on using Crowd with other Atlassian products

[Anurag Jalan]

1. We will integrate Crowd with our Production AD/ LDAP for user authentication
2. All applications (JIRA, Confluence, Bamboo, Bitbucket) authentication will be via Crowd
3. We want to restrict permissions for users at Project & Space level in JIRA & Confluence respectivley. It means that user 1 may have access to Project A only in JIRA & not to other projects. If required, we will provide him access to other project which will be on case by case basis. Similarly for Confluence as well. We want to do this since we don't want to expose all projects/ space info to every user by default as per pur organization guidelines
4. Note: we will have around 100+ Projects in JIRA & 50+ Spaces in Confluence 
5. Take JIRA for example. We will have three groups for each project - administrator, Lead & User. For these, I can create three security groups in AD for Project A. I can import these groups in Crowd & configure under Project A in JIRA. Done. When a user needs access to Project A as Lead, we or service desk can add that user under particular security group & user has access
6. Now when we create a new project B in JIRA, again we will need to create three new security groups in AD and follow the same process. This will increase no. of security groups in AD with time & may be difficult to manage with respect to audit & all.
7. Is there an industry standard recommended by Atlassian for managing this.

Please advise. Happy to provide more info.

[Anurag Jalan]

Please note that per our security guidelines, we need to onboard these security groups in Infosec portal when application is go-live. With above approach, I can't ask Infosec to keep on adding more security groups into their portal whenever new project or space is created. They won't allow it.

So is there a way to have few standard groups across each application which we can onboard. Now whenever, new project is created, we manage the groups locally somehow or any other way.

At time of audit, when it is asked, who all have access to JIRA, that can be derived from security group. If asked, which user has access to which particular project in JIRA, that can also be derived without any issue.