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).
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?
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
A picture tells a thousand words. And agility boards have just released their latest feature: cover images on issues – so now your board can tell a story at first glance. Upload attachmen...
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!
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