local authentication vs. jira user management

Hello everyone,

how did you ensure you could run your 
companies authentication and user management
with the JIRA system?

What do you all use, LDAP, active directory, something else?

 

3 answers

1 votes

All of them, I've seen JIRA hooked up to all sorts of user directories.  I've even seen it use a non-directory method, where certificates were handed out.  Of course, most organisations have some form of LDAP (that includes AD, same basic idea).

What you mean by handing out certificates? Using some kind of software certificates from a pki?

Both is some sort of a remote user management isn't it?

Yup.  JIRA was not hooked up to a directory (like it is with LDAP and the others).  Imagine it more like having a swipe-card (certificate) to your office (JIRA).  Present the card and it goes "Ah, you can come in"

But when using a swipe-card or a smartcard the user management is done by the pki system rather than the JIRA system? In that case how does JIRA knows which user shall be logged in and which user role or which user group he or she belongs to?

Anyhow it seems that you need a plugin which will handle the communication and authentication with the ldap system or the pki system?

Not quite.  JIRA bases its accounts on the certificates, there's no external links.  Group management is done in JIRA for JIRA.  You are absolutely right about the need for an add-on - it contains a replacement authenticator as well.

So the user management is done by JIRA itself, including the users, the roles and permissions etc and an admin have to add every single user?

What about doing the authentication via ldap or active directory or another remote directory service? When the user authenticates against ldap what about the permissions and user roles in JIRA?

If you're talking about the certificate stuff, it's the opposite.  Certificates are handled by a discrete system that doesn't know (or care) about other systems.  It hands them out, and publishes revocation lists.  Other systems such as JIRA are set up in a way that simply blocks access to anyone without a certificate (and bins revoked ones), but if they present a valid one, lets them in and takes the user info from it.  Roles and permissions are given a broad default (you are automatically in the HR and Help-with-atlassian-apps projects), but because they use roles exclusively in there, the project admins are then free to add the new people as they require.  The authentication is done by certificate.

Off the shelf, JIRA supports many types of directory, and has levels of access - it  can range from a minimal "do everything in JIRA, except the password check is delegated to the directory" through to "JIRA can manage the directory groups as though it's a directory administrator".  Most places use the middle-ground - users and groups are in the directory and JIRA only reads them.  JIRA only does users and groups though, not roles.

So even when using an AD or ldap system, the users have to be added in JIRA itself?

And the JIRA username should have been inserted in the actove directory?

No.  What would be the point of having an external directory that doesn't actually provide users?

I'm a bit lost on what you're looking for here.

Sorry my fault. Of course you are right that there would be no point at all using a directory which does not provide users.

Actually It is to figure out which information (user, groups, roles, permission) is stored where and how to get the information.

But anyway. Wou helped me a lot. Thanks a lot.

Ah, I see.  Well, the basics would be some form of unique login id (username), and password authentication.  JIRA will then take email, display name, and group memberships if you need it to.  There are some add-ons for some directories which allow more information to be drawn out of the directory for display and other uses (eg. showing a department, telephone number etc)

Permissions and Roles in JIRA are internal constructs and would require an external directory to understand JIRA projects for it to be held there, so they can't be done in the directories.

We run everything off our enterprise AD and wrote a couple big LDAP filter queries that starts with the department-wide AD group to pull in all users, then recursively goes through all their group memberships and pulls all those groups in.  We then piggyback Confluence off of the JIRA user directory.  This allows us to have identical users and groups so we can permit and restrict information easily across both systems using our already established AD groups instead of building local groups in JIRA.  The only local groups we use are the three built-ins, jira-users, jira-developers, and jira-administrators.

@Paul Thanks for the detailed description.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,963 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot