SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000076SiT!authenticationpublic2008-07-11 18:052009-08-16 14:39
Assigned Topaulh 
PlatformOSOS Version
Product Version 
Target Version3.50Fixed in Version3.50 
Summary0000076: Directory integration - LDAP
DescriptionAdd LDAP authentication and lookup for users/groups/passwords instead of
making the poor sysadmin maintain multiple user databases.
It would be best to use LDAPv2 so as to be directory-agnostic, since MAD
isn't LDAPv3 compliant. That way, you could use OpenLDAP, eDirectory or
MAD, and assign your user objects to SiT!-specific groups in the directory,
and have the same functionality as the standalone user database entries.

That could extend as well to any white-pages type demographic info, like
office, extension, fax, location, department, etc.

You'd have to correlate an LDAP user with a user placeholder in the user
table to keep the links alive but it would be a really nice feature.
TagsNo tags attached.
Attached Files

- Relationships
related to 0000078closed Open ID authentication 
parent of 0000346closedpaulh LDAP sync should never touch admin user 
parent of 0000735closedpaulh log in error 

-  Notes
User avatar (0000008)
kieran (administrator)
2008-07-11 18:05

Date: 2008-04-17 09:06
Sender: ivanlucasProject Admin
Logged In: YES
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

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
( [^]) 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
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
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
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

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

Date: 2008-04-16 18:08
Sender: ivanlucasProject Admin
Logged In: YES
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
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
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

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 == 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
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.
User avatar (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 - [^]
<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 [^]
<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> [^]
<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> [^]
<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





User avatar (0000221)
ivan (administrator)
2008-11-27 16:11

Stonekeeper has written basic LDAP support, see patch SF#:2353594 [^]

accepted as trunk svn r4258
User avatar (0000412)
ivan (administrator)
2009-01-06 09:54

Initial LDAP Support will be released in v3.45

See [^]

For Documentation.
User avatar (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
User avatar (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

Copyright © 2000 - 2021 MantisBT Team
Powered by Mantis Bugtracker