0000076: Directory integration - LDAP

Notes
(0000008) kieran (administrator) 2008-07-11 18:05	Date: 2008-04-17 09:06 Sender: ivanlucasProject Admin Logged In: YES user_id=1456679 Originator: NO Yes by contacts Paul and I mean customer contact information, in SiT we store customer data in a MySQL table called 'contacts'. vCard import is a good idea, I think I'll log that one as a separate feature request, we do already have vCard export. I don't think we should use LDAP for these records. SiT group membership differs from directory group membership in that with SiT a user can only be a member of a single group whereas a directory allows a user to be a member of many groups. Perhaps, as you say, we could just check (say) that a user is in the 'Staff' group in the directory and if he is put him in the staff group in SiT (ignoring any other non-recognised group memberships). We'd need to be careful in case a user was in two directory groups that matched two SiT groups though. Role is separate to groups, it indicates which permissions are available to users, but it does work in a very similar way so perhaps this again could use directory group membership. e.g. a user could be a member of the Staff group and the Managers group which would set his sit group to Staff and his sit role to Manager. My feeling is that we should put this on the roadmap (http://sitracker.sourceforge.net/Roadmap [^]) for 3.50 or perhaps 3.60, as we've a lot of work to do making SiT more stable before we add features such as this. What do others think? btw Please not outlook, I think I'd rather have a frontal lobotomy. :-/ Date: 2008-04-16 22:55 Sender: jstalewski Logged In: YES user_id=2063821 Originator: YES WRT contacts - are you talking about the demographics info on user objects - the usual x.500 user object attributes, or are you talking about an actual contacts list as in what one would have in a CRM? If you're talking about not obtaining the user attributes via LDAP, I don't see why not pull that info on first login, to populate the fields - as long as the directory meets LDAPv2 spec at minimum, and holds to x.500 attribute mapping for that info, that's not a can of worms, IMHO. I agree, for things like vendor contacts, customer contacts, etc - no to LDAP for that - but for the user info, I say go for it. (watch, the next request will be for integration with the Outlook address book - ecch!) I like the idea of sticking with open standards as much as possible, and I haven't delved that deeply yet into the product, but for example if you don't have a vcard import for contacts, I'd think that would be groovy and still in keeping with the idea of sticking with standards, without reaching for the can opener. However, maintaining contacts as a separate entity from user demographic data, the concept of user demographic data coming from LDAP is still a "hmmm... maybe..." from my perspective anyway, rather than "nope. A user's phone number is 'contacts.' Can't do it." Again, tired. Forgive my ramble. Date: 2008-04-16 22:33 Sender: jstalewski Logged In: YES user_id=2063821 Originator: YES Would SiT group membership have to be an extended attribute and not actual directory group memberships? Do they not serve the same purpose? Or am I missing something in perhaps the database structure - is there for example a key relationship between the user and the children of group/role functionality (I hope that makes sense - it's late and I'm tired...) I'm not suggesting that the directory service actually provide the linkages that the group entities in SiT do - just that membership be conferred through directory group membership. The gotcha would be who's boss, I suppose. What you could do is make sure that whoever is granted group-creation permissions in SiT also has group-creation permissions in the DS, and that the LDAP auth is sufficient to confer the group creation rights when you send the command via LDAP to create a group. The only thing, once a group is created, would then be to add or remove the user from the group based on LDAP membership lookup. The rules for group creation would have to be part of the config when LDAP integration is set up - context, etc. and to make it directory-agnostic you'd have to make sure that groups can't be nested. Date: 2008-04-16 21:19 Sender: paulheaney Logged In: YES user_id=1496915 Originator: NO I agree a config option + documentation of how to extend the schema of eDir, OpenLDAP and MAD (with the posibility of more if people can provide these). I was thinking the contacts would work the same was as the users in that SiT creates an entry if one doesn't exist the main reason I feel this is important is if people are using the SiT portal then they will have a different SiT password compared to the directory one. I'm thinking of a university using SiT to track internal requests you'd have to have a SiT password and your DS password. Whilst you can get around this with a IDM system not everyone has a IDM system. I dont think supporting LDAP contacts would be opening the flood gates the main reason for implementing this would be the passwords for the user portal. Date: 2008-04-16 18:08 Sender: ivanlucasProject Admin Logged In: YES user_id=1456679 Originator: NO Yes if there are permissions we could push the changes back, the attributes that are able to be modified may vary by directory and implementation so I'm not sure how we'd layout the config options for it. Extending the schema is not realistic for those using Active Directory, we'd be best to offer a config variable and let admins choose which attribute to store the data, if they want to reuse an existing but uncommonly used attribute they can, if they want to extend the schema and use a new attribute they can do that also. Even though some SiT users may have directories with contacts in I don't think this is enough reason for us to use LDAP for storing contacts. Ignoring the not insignificant technical issues, (such as how do you do a SQL join with a remote LDAP directory), we'd be opening the floodgates to supporting every type of contact/customer data-store in existence. There are plenty of existing tools to do a database sync, and as the example you give proves, it's possible with Novell IDM. Date: 2008-04-16 10:25 Sender: paulheaney Logged In: YES user_id=1496915 Originator: NO Had forgotten about additional attributes, its common these days for users to have rights to change the phone number etc so we could possible make this a config option for the change to be pushed back into the directory. As for the groups I'm not keen on using an attribute that could be used somewhere else, probably better to extend the schema with an additional attribute for sitGroup (or userdefinable) - this might be better as a documentation item rather allowing admins to setup how they want. As for the contacts in the way Salford use SiT then it makes sense to us the MySQL though most organisations who are using it to support there users (companies, universities etc) will already have the users in the directory so would make some sense though depends on demand. Internally at Salford we use Novell IDM to sync contacts between our portal eDirectory and the SiT database. Date: 2008-04-16 09:39 Sender: ivanlucasProject Admin Logged In: YES user_id=1456679 Originator: NO Using LDAP for authentication is a good idea, I think this is something we've known we'd have to do at some point before we could ever call SiT feature-complete. It would be fairly easy to implement. We'd just need to change the authenticate() function to support LDAP as well as MySQL. I envisage it would work like this: $CONFIG variables would set up the pairing between SiT fields and Directory attributes. e.g. SiT users.phone == ldap.telephone. On login the authenticate() function would retrieve the paired attributes and store them locally in the MySQL database and also in the users session. If the user logging in does not already have a local record in the MySQL database then one would be created. The paired fields would be treated as read-only within SiT, that is, when using LDAP authentication it would for e.g. not be possible to change the users telephone number from within SiT. I think we'd have to do this because we couldn't guarantee that we would have write permissions to be able to change the attributes in the directory. SiT Groups are an issue, we'd have to work something out for them, specifying a spare attribute such as Notes perhaps and storing the group, role (and possibly permissions?) there. I'm less keen the idea of using LDAP for customers/contacts, there are a million and one places one could store customer data and I think a directory is probably one of the rarer places. Another SQL database would be more common I should think, and supporting every type of address book database is probably beyond what we could achieve with SiT. Date: 2008-04-16 07:23 Sender: paulheaney Logged In: YES user_id=1496915 Originator: NO Hi Jim, I agree this would be a very useful feature, what I would imagine would be that you'd have a group in your directory say situsers and anyone a member of that can log into SiT as a user we'd probably have a scheduled event which would create users in sit as a type ldap and when the login we check there password in the directory and cache it in SiT (so sit keeps functioning even if the directory fails) if the user isn't in SiT already then we'd do an LDAP lookup and try and locate them if they exist and are a 'situser' then we'd add them in. The one thing which could cause problems is if a user is a memeber of more than one group where do they go in SiT? (In our eDirectory I'm in both the support and development groups though in SiT I'm in support). What I'd like todo is take this idea one step further and use the directory as a source of contacts if your using SiT as an organisations call tracking system then they'll already exist in eDir and it saves having to duplicate admin overhead again. Comments welcome.

(0000208) ivan (administrator) 2008-11-25 10:09 edited on: 2008-11-25 10:10	From IRC 24Nov08: <Stonekeeper> hi there. If it wasn't for the lack of LDAP support, I'd be using sit right now. So I was thinking of attempting to add it in. Have there been any moves on this front before i start or is it all in the air? thanks! :) <ericthefish_> hi <ericthefish_> it's been discussed but I think thats as far as it went <ericthefish_> I think theres a feature request open for it, hang on <ericthefish_> yeah there is <ericthefish_> bug 76 <sitbot> Bug 76 - kieran - new - open <sitbot> Directory integration - LDAP - http://sitdemo.salfordsoftware.co.uk/mantis//view.php?id=76 [^] <ericthefish_> you'd be welcome, more than welcome!! to code it if you feel like jumping in ;) <ericthefish_> I'm pretty sure if you started that there would be other people willing to help <Stonekeeper> ok, I've not had chance to dig deep yet, but I was going to implement it like this: 1. See what data is needed for the sql backend, 2. Bind to the ldap server to check for credentials, 3. on sucessful bind, sync user attributes to the database (yes, i think each time to pick up changes to email etc but keeping the users primary key/id) <Stonekeeper> this is purely for manager/operator/customer login <ericthefish_> yeah, so using the directory as the master copy for email address etc.? <Stonekeeper> indeed <ericthefish_> sounds reasonable <Stonekeeper> the only reason for syncing to db was so i didn't have to change any existing php <Stonekeeper> * apart from authing of course <ericthefish_> the hard bit with that perhaps, is that we have two tables, users and contacts, that seperate real users from those being supported <Stonekeeper> do you know if users are identified by a unique ID? If so, and this doesn't change, then i think it'll be possible <ericthefish_> yeah users have two unique bits, there's a numeric ID, and a text username which also much be unique <Stonekeeper> ok, real users being operators/managers and contacts being customers (who could log in via a portal)? <ericthefish_> yeah thats right <Stonekeeper> for ldap that's no problem <Stonekeeper> presumably at the moment the numericID is auto generated? <ericthefish_> yeah it's just sequential <Stonekeeper> great <Stonekeeper> then just use uid for the "name" <Stonekeeper> username <ericthefish_> could do <ericthefish_> or we could create another field? <Stonekeeper> well is username the name they log in with? <ericthefish_> yes it is <Stonekeeper> ok, but there are fields for firstname/surname etc? <ericthefish_> yeah <Stonekeeper> then i see no problem <ericthefish_> ok fine <Stonekeeper> all that's needed is successful creds and an ldap attribute map <ericthefish_> I suppose we'd just have a config variable for the attribute to use <Stonekeeper> you'd probably need a map/dictionary <ericthefish_> i guess so, there's more than just one isn't there <Stonekeeper> sql.attr = ldap.attr <Stonekeeper> wait, it's been a while since I phped.... does php have dictionaries? <ericthefish_> yeah <ericthefish_> not as such, but you can do very similar things with arrays <Stonekeeper> $myvar = array['text_identifier']; ? <ericthefish_> yeah that kind of thing <Stonekeeper> ok. I really fancy doing this <ericthefish_> brilliant! <ericthefish_> you probably want to read this to get started http://sitracker.sourceforge.net/DevelopmentHowTo [^] <Stonekeeper> also, a neat feature of otrs that i saw was limiting authentication based on posix group membership <Stonekeeper> ah yes, I've seen that link <ericthefish_> right yeah, we have wondered about that I think <Stonekeeper> in otrs you give it a DN and an attribute (normally memberUid). Works well <ericthefish_> we have 'roles' which kind of map to a set of right/permissions <Stonekeeper> ah ok, how do they work? <ericthefish_> at the moment there are only 3 predefined roles, admin, manager and user. but that can be extended to support any number of them <Stonekeeper> (I was thinking more of limiting at the auth stage, although mapping groups to roles makes sense) <ericthefish_> so I wonder if we could have role = posix group somehow <Stonekeeper> indeed <Stonekeeper> however there are 2 scenarios here <Stonekeeper> 1. Limiting of authentication <Stonekeeper> IE: You have ITAdmins and Staff groups <Stonekeeper> ITAdmins are part of the staff group too <Stonekeeper> but you'd limit the roles of manager and admin to ITAdmins <Stonekeeper> and Customer to Staff group <Stonekeeper> however, you couldn't magically assign a role based on that because it's not 1:1 <ericthefish_> mm yeah that gets more difficult, our roles are a bit primitive, each user can only have one <ericthefish_> at the moment anyway <Stonekeeper> ok, so as an admin, i could not open a ticket for me? <ericthefish_> we grant pretty much everything to admins anyway, so yeah you could <Stonekeeper> ok, but i could not log on as a customer and view it? <ericthefish_> no not that bit <Stonekeeper> hmm.. ok that might not be an issue <Stonekeeper> although i can forsee someone somewhere requiring all users be customers <ericthefish_> it's because the customers use that seperate table and they don't use roles at all, users aren't classed as 'users' in sit, they're 'contacts' <ericthefish_> sorry, customers aren't classed as users, that was confusing! <Stonekeeper> :) <Stonekeeper> ok, so how about this: <Stonekeeper> 2 maps: ldap->sql, username->role <ericthefish_> not sure what you mean there, is that storing the role in ldap? <Stonekeeper> otherwise, there's no way of determining what role a person is when they log in surely <Stonekeeper> no <Stonekeeper> ok, to be clearer: how are roles stored? <ericthefish_> the users table has a column 'roleid' <ericthefish_> which maps to a list of permissions in another table <Stonekeeper> right <Stonekeeper> I'll put an example in pastebin <ericthefish_> ok, ta <Stonekeeper> http://sit.pastebin.com/m1e155f78 [^] <ericthefish_> got ya, yeah that looks good <Stonekeeper> because you don't store the role in ldap (and I'm pretty sure you'd not want to), you'd have to map somewhere <ericthefish_> I wondered in the past if you'd want to use something in ldap, just because this means an administrator does need to have something else to manage his users, he can't just use the directory soley <Stonekeeper> the only thing i think you'd have to be aware of is changing roles. <Stonekeeper> as an ldap admin, i would not like to add schemas <ericthefish_> no wasn't thinking that, was thinking more of which container the user was in <Stonekeeper> although it'd be easy to use an existing attribute. The pain is then setting up write access to that attribute etc <ericthefish_> e.g. if you have your staff in the 'Staff' group, you'd use that <Stonekeeper> if sit was multi-role this would work <ericthefish_> yeah... hmm <Stonekeeper> but my example before shows that it's not possible at the moment, hence the map <ericthefish_> the map is good, but it perhaps adds a bit more burden on the administrator, he's now got LDAP and the map to manage, not just LDAP <Stonekeeper> true <Stonekeeper> ok, i got it <Stonekeeper> 2 secs - pastebinning <ericthefish_> :-) <Stonekeeper> http://sit.pastebin.com/m33d0adb7 [^] <ericthefish_> yeah perfect, like that <Stonekeeper> so then the admin just admins posix groups <Stonekeeper> that's what i was saying is in otrs, and i liked it <ericthefish_> yeah thats much easier, should only require setting it up once <Stonekeeper> the only issue you have (!) is multi group membership <ericthefish_> well yeah, I think for now theres not a lot we can do <Stonekeeper> but i guess you'd just choose the highest priority group as your default role <ericthefish_> yeah <Stonekeeper> if i'm in the customer AND admin group then I'm an admin <ericthefish_> yeah, SiT isn't complicated enough to need more than that in most cases anyway <Stonekeeper> ok, i feel we're getting somewhere <ericthefish_> :) <Stonekeeper> now then, attribute syncing. I'm guessing stuff like phone, email and surname would need syncing each time <ericthefish_> I think so <Stonekeeper> Only those 3 maybe? <ericthefish_> just looking now <ericthefish_> the other one is 'mobile' and maybe 'title' (which is job title) <Stonekeeper> is there a way of renaming a user? You know that unique text username you mentioned <Stonekeeper> yes those 2 as well <ericthefish_> not from within SiT no, but you edit the database directly of course <Stonekeeper> ok. I'm just thinking of women who get married <Stonekeeper> so they get a new username, they log in and have 0 history :) <ericthefish_> thats true, you can change name but not username <ericthefish_> we actually have firstname and last name as one field, "realname" <Stonekeeper> ok, i could map that from cn or gecos or something <Stonekeeper> ie, only 1 attribute <ericthefish_> we could provide an admin feature to rename usernames if thats needed <Stonekeeper> i'm just thinking that it may be useful regardless of authentication issues <ericthefish_> I think* we were going to make it so you could login by email address as well, not sure if that got done yet <Stonekeeper> some people get funny about using their maiden names ;) <ericthefish_> heh yeah! <Stonekeeper> same problem though <ericthefish_> well yeah it is quite often <Stonekeeper> firstname.lastname is very common <ericthefish_> with email it would sync'd from the directory though, username is just expected to match <Stonekeeper> uid or mail, it makes no odds <Stonekeeper> they are both single attributes <Stonekeeper> we use ldap all throughout so people are used to logging on with username <Stonekeeper> but we have zimbra mapped to their account too so that they can logon with email addresses <ericthefish_> so if somebody attempts to login for the first time, it would create a new 'user' record for them, and then on subsequent logins it would sync the attributes you mentioned? <Stonekeeper> i'd imagine that's the best solution <ericthefish_> ok ================ ldap.conf: [LDAP] host="" bind_dn="" bind_pw="" (ETC) [ROLES] customers="<some_dn>" admins="<some_dn>" managers="<some_dn>"

(0000221) ivan (administrator) 2008-11-27 16:11	Stonekeeper has written basic LDAP support, see patch SF#:2353594 https://sourceforge.net/tracker2/?func=detail&aid=2353594&group_id=160319&atid=815374 [^] accepted as trunk svn r4258

(0000412) ivan (administrator) 2009-01-06 09:54	Initial LDAP Support will be released in v3.45 See http://apps.sourceforge.net/mediawiki/sitracker/index.php?title=ConfiguringLDAP [^] For Documentation.

(0001427) paulh (administrator) 2009-07-26 19:20	trunk r5665 add LDAP integration which supports eDir, AD and OpenLDAP this will be released as part of 3.50

(0001715) ivan (administrator) 2009-08-16 14:39	Released in 3.50rc1

Issue History
Date Modified	Username	Field	Change
2008-07-11 18:05	kieran	New Issue
2008-07-11 18:05	kieran	Note Added: 0000008
2008-07-12 11:16	ivan	Relationship added	related to 0000078
2008-07-17 13:15	ivan	Category	other => authentication
2008-11-25 10:09	ivan	Note Added: 0000208
2008-11-25 10:10	ivan	Note Edited: 0000208
2008-11-27 16:11	ivan	Note Added: 0000221
2008-11-27 16:11	ivan	Status	new => confirmed
2009-01-06 09:54	ivan	Note Added: 0000412
2009-02-07 13:25	ivan	Relationship added	parent of 0000346
2009-06-16 17:47	ivan	Relationship added	parent of 0000735
2009-06-16 18:55	paulh	Status	confirmed => assigned
2009-06-16 18:55	paulh	Assigned To	=> paulh
2009-07-26 19:20	paulh	Note Added: 0001427
2009-07-26 19:20	paulh	Status	assigned => resolved
2009-07-26 19:20	paulh	Resolution	open => fixed
2009-07-26 19:20	paulh	Fixed in Version	=> Current SVN
2009-08-15 21:31	ivan	Target Version	=> 3.50
2009-08-16 13:15	ivan	Fixed in Version	Current SVN => 3.50
2009-08-16 14:39	ivan	Note Added: 0001715
2009-08-16 14:39	ivan	Status	resolved => closed