local authentication vs. jira user management

[Titus]

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?

[Nic Brough -Adaptavist-]

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).

[Titus]

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?

[Nic Brough -Adaptavist-]

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"

[Titus]

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?

[Nic Brough -Adaptavist-]

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.

[Titus]

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?

[Nic Brough -Adaptavist-]

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.

[Titus]

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?

[Nic Brough -Adaptavist-]

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.

[Titus]

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.

[Nic Brough -Adaptavist-]

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.

[Titus]

@Paul Thanks for the detailed description.

[Paul Stallworth]

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.