|
[
Permlink
| « Hide
]
Adam Harvey added a comment - 07/Jul/03 06:35 PM
Jeff- In our case, we have a corporate LDAP with over 10,000 users where we'd want to authenticate against (single sign on) and use it for profile data. However, at this time the corporate LDAP does not contain group information to the granular level we'd like, nor for us to create/modify. It'd be good to be able to use JIRA to create an Admin group, and maybe even JIRA groups based on profile data (eg, all users in New York office, or all users who's manager is Employee #43043). Our LDAP as is only contains large groupings, such as line of business or geographic location, rather than my own team of 7.
Hi Adam,
Thanks very much; just the sort of feedback we're looking for. Based on this, it sounds like a user's group should be determined by the success or failure of an arbitrary LDAP search. That would allow us to define a virtual group for "all users who's manager is Employee #43043". --Jeff We picked JIRA for eval because of it's LDAP support.
AS a matter of fact, I refuse to look at any software for our intrante that does not support LDAP. 
It would be neat if you could add support for LDAP Groups so that you can create a full JIRA account out of LDAP information. Without haviong to create the user in JIRA. Furhermore, a hook for Single-Sign-On would also help a lot. Cheers, And for the groups:
We store groups in LDAP, or more precise in ActiveDirectory. But we have a custom schema, because each location is administering themselfes. So we would have trouble if you hard-wire the LDAP query. Make it configurable, please. Slowly, we are re-creating LDAP groups in JIRA which is "not so hot". Is there a way that we can contribute?
We have a complete set for LDAP integration with JIRA (ProfileProvider, AccessProvider and modified CredentialsProvider), we do not use hardwired LDAP queries, and would suggest you do not use them as well. Our osuser config looks like this:
<provider class="com.opensymphony.module.user.provider.ldap.LDAPCredentialsProvider"> <property name="searchBase">o=companyname,c=countrycode</property> <property name="exclusive-access">true</property> </provider> Here the "query" property is a template for real ldap search query, I apologize to the user community but I'm ashamed to release our current modules, they are awfull mess. This is not something that should be associated with our company in any way At least in our organization, the groupings in Jira and in LDAP partially match each other but some groups wouldn't make sense if they were in both.
Ideally Jira's group admin would allow for arbitrary LDAP queries which would produce group, allow for direct group importing in groups were already present and then let the admins create jira-only groups. For the LDAP-based groups, please create an interface which lists all the available groups from LDAP with giving the admin the option of choosing which groups should be used in JIRA (ie, visible in the other interfaces) and under what name. In our organisation also, LDAP server (Active Directory) is used, so it's necessary to use it from JIRA, but we would like to use groups defined in JIRA AND groups defined in LDAP.
It's the same for users : we should be able to use JIRA accounts as well as using LDAP users. Of course, LDAP groups should contain only LDAP users, but JIRA Groups should contain JIRA and LDAP users. these needs are because we want to use JIRA for internal and external users. Internal users are stored into LDAP, but external users must be stored in JIRA databse +1, definitely we also need what Richard describes. at least, we do need to use LDAP with groups, and not only for authenticating: we are already defining roles for our applications. The LDAP integration in JIRA is our next step to simplify user administration. But we need a Active Directory group mapping to JIRA groups because of our existing naming conventions in AD.
A Single-Sign-On integration is not very simple due to the SPNEGO (Simple and Protected GSS-API Negotiation Mechanism). I know only the product JCSI SSO from Wedgetail. I hope that someone knows how to combine JCSI SSO and OSUser. Links: I'd suggest looking at how mod_auth_ldap in Apache works.
Basically, it uses groupOfUniqueNames. So, you specify that a bit of the app is restricted to members of the groupOfUniqueNames identified by a DN. So, given a base, maybe plug in the project key to find who has what privs: such as cn=pico-developers,ou=pico,ou=projects,o=codehaus Grab that object, and iterate to see what the members are (defined by their DNs). We're still on JIRA 2.5.3 (until our Weblogic platform is upgraded to SP2 WLSv8.1 to fix a JSP translation issue).
One minor issue for us is that all our users are in LDAP (external) however JIRA still offers the CHANGE_PASSWORD functionality on the edit profile screen (from what I see), however this does not make sense. I'm not sure of the exact impact of turning ON external user management, however with this on it is still possible to get to this change password functionality, which we can use to change a password, however the password doesn't really get set in our LDAP external repository so it is confusing for the user. So for us, whilst externalising groups is not an immediate need, addressing the above at least would be good. Hopefully these comments are relevant to this issue. Thanks. PS For our home groups apps we use Weblogic Novell authentication provider which has all the appropriate settings for configuing ldap user and group details (e.g. search bases etc). Have you considered LDAPS support with the LDAP integration? My internal security team won't let me hook anything up to LDAP that isn't using LDAP over a secure connection.
Managing groups within Jira is fine for us as there are far more granular groups in Jira than we have in our LDAP (Active Directory). Hopefully the level of integration with LDAP will be configurable. Alyssa,
LDAPS is supported on Java 1.4.2 and above. Just specify ldaps://... in your URL We are pushing ourselves into full LDAP'ing as well. We've been pondering using <a href="http://www.mirapoint.com">Mirapoint</a> as our MTA since I'm looking to absolve a lot of internal workloads through growable appliances. Mirapoint though makes their own oid/schema to store their data along side your own within your LDAP configuration for playing like active directory/exchange.
It looks like its going to integrate very well with our existing user base. Is this an idea that Jira will be employing? Create its own inheritable schema for permissions/grouping? Would that be easier than trying to integrate with posix grouping? If you span multiple departments all with the same wheel ideas the overlap might not give the permissions as intended for each group. 2c, I'll vote for the flexible approach, although I realize this means more work for you. But, based on current product, I have complete faith that you will be able to pull it off. In general we don't want to be limited or forced to implement a unique schema. The whole point of LDAP (in my mind) is one stop shopping. I want to add a user in one spot and then authorize (sorry, authorise) them to access various systems and applications. I don't want to have to add a user in one LDAP tree for system authorization, and then add them to another tree for services like Jira. Likewise, I don't want to have to add a generic first name/last name attribute AND a Jira_Firstname Jira_Lastname attribute for a Jira profile.
So for the user authentication piece, I agree with Grigoriy V. Kuznetsov that we should be able to define our own search filter resulting in a list of valid entries against which authentication occurs. This way if I want to allow users to access Jira based on group membership, I can do that. Or, if I want to allow users to access Jira based on a custom attribute or object type (perhaps JiraUser, for example), I should be able to do that too. However, getting LDAP integration to work can be quite a trick. And modifying schemas and understanding the nuances of search filters can be quite daunting. So, it should work out-of-the-box without much customization (ie authenticate against uid=username,dc=example,dc=org). I also agree with Richard THIBAULT about the ability to have "local" Jira users and groups that don't appear in the LDAP directory. So add +1 for me to his comment. Finally, changing LDAP passwords: Our configuration choices should be at a finer level, an option like "Can user change password". If jira can pull off changing an LDAP password, great, but I still want the choice of limiting where my users can change their LDAP password. Maybe I want them to change their password through an internal page that lists corporate password policies, etc. In this case, I don't want Jira to even offer the choice (or maybe give a customizable URL pointer to where they can). Or maybe I don't care where they change their password, just as long as they change it. Anyway, I look forward to seeing the final result. I'm sure it will be great! We too would find deeper LDAP integration valuable. We use AD to manage some 15,000 accounts. I see the need for group authentication from LDAP for divisional and business unit access that's managed centrally and a need for groups managed within Confluence (our current interest) where users fall across the line of business silos.
This issue still hasen't been scheduled.
Any hope that this will be resolved in the near future? We are discussing implementing this with a customer who is willing to fund some of the development, so it may happen within the next few months.
We use Oracle OID for all user management, I was a bit dissapointed when I hooked up Jira with the new LDAP integration, just to have to continue creating users. Furthermore, I had to go to a few JSP pages and kill the forgot password links etc.
Jeff, what is the statuf of this one? We, like many others, want to start using Jira for support issue management, and this is a blocker for that right now. All our internal and external users, and groups, are available in LDAP. We really really don't want to double-manage them.
Rickard,
We are hoping to put someone on this in the next few months. I can't give you a more accurate timeline than that, as it depends on hiring of new developers. Cheers, Confluence administration allows delegation of user management to Jira. This is nice, but there might probably be some added granularity so that project managers can add individual users to projects and/or groups using the GUI.
Regarding use of LDAP. Sounds great. We also use Oracle's dbms_ldap package to synronize external DB with Oracle's OID. We've written LDAP triggers to externalize managing users. Would like to do same for Jira. Haven't found example of how to do that yet. Could you get with Oracle to formulate an API much like they already have so that our triggers can hit Jira as well? If you like, I could give you the name of an OID expert who you could contact. Charlie We use CVS integaration which is tied to OS user. But only developers are on CVS and not business users who files bugs, are not on the OS on Unix/Linux box. We may need generic OS group access for business users if we were to tie OS group/users to Jira and LDAP. (Most of the projects would exsists on CVS). Just a thought ..
Kiyomi - May 12, 05 I don't particulary care about having some Jira information stored in Jira. In fact I might say I prefer this. If it's Jira specific, that's where it belongs, right?
What I would like is a more flexible way to link LDAP accounts to the Jira information. When a user logs in, I want the user object to be located by sAMAccountName, but I want the Jira information to be linked based on gUID. The Account name of the user may change!!! THe guid will not. This would basically mean the integration of a new LDAP config setting: unique.attribute, or something. For us, even a very incremental step would be a huge improvement. We have all of our users, many thousands, stored in LDAP. It would be nice to point JIRA to that LDAP instance and have JIRA automatically create their JIRA account the first time they log in. Seems like it would be fairly simple for JIRA to bypass the simple 'Create User' screen, pull those few fields from LDAP and push them into JIRA. That would alleviate me from the burdon of manually entering those names in to JIRA.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Major
Migrate to Atlassian User (externalised LDAP management)
