I'm wondering if anyone has some good insight on handling shared service accounts when your instance is open to the internet?
My org has been trying to solve this issue before fulling allowing "service accounts" for our users to automate processes using Confluence. Our user base is sourced from AD. Service accounts would also live in AD and be synced to Confluence via a User Object Filter for the AD user directory.
The main concern is maintaining the privacy and security of these accounts so users do not share the credentials amongst each other or continue using them after they have left the company.
We've thought of the following possible solutions:
We've also reached out to Atlassian who has basically said, "You shouldn't do it that way. Consider removing this scenario from your environment." without any kind of guidance on how to accomplish our needs outside of upgrading to 7.9 and using tokens. However, I'm finding it hard to see how tokens resolve this issue? Users would still be able to share the login account name and token and then authenticate, no?
We are currently on the 7.8 branch so using tokens is not an option yet, but we are investigating that as a solution. However, to my understanding, that still doesn't address "user's sharing tokens for access to the API with each other without administrator knowledge."
Also, we can't just inform our users to store their own credentials in scripts... that's ridiculous.
Any implementation examples or guidance is greatly appreciated!
Hi Community! We're thrilled to share that Team Calendars for Confluence is now a built-in feature for Confluence Data Center releases 7.11 and beyond. A long time favorite, Team Cale...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events