OTRS for Customer Companies using LDAP
Hi there, My name is Jeroen van Meeuwen, and I'm relatively new to OTRS. I wanted to acquire some feedback on the following scenario, since I didn't seem to able to simply deploy it using current OTRS functionality. Kolab Systems AG is the vendor for Kolab Groupware solutions, and as such mostly supports it's customers through a Partner channel system. In a nutshell, Partners help the customer and Kolab Systems helps the partners. Long story short, these Parters (to us) are Customer Companies, and so inherently we want all employees of a partner to have all tickets logged by any other employee of that partner be available in their customer interface. Since we are using a centralized LDAP backend for both agents and customer authentication, it seems that the proper solution suggested in the OTRS documentation, is to make one or the other LDAP attribute represent a list of "CustomerIDs", and use it to attach such attribute to a single customer LDAP entry. However, considering we need this to be a full mesh, the administrative overhead would be enormous. Since, also, this is a business related effort, we can safely assume that partner employees all have the same domain name space for their email addresses. Ergo, employee1@company.com is very likely to work for the same company as employee2@company.com. I've implemented the following functionality; In otrs/Kernel/System/CustomerUser.pm, instead of populating the CustomerIDs the user also has access to through a list of CustomerIDs from an LDAP attribute, I use the @company.com part of the email address and simply find other people also using @company.com (and stuff those email addresses in the @CustomerIDs list). Now, the implementation I've done is simple, dirty and quick (patch attached). However, since the application may help many more organizations, and since Kolab Systems is a very much FOSS-minded company, they are willing to let me work on this with you. That is, of course, if you find it sufficiently interesting to have this developed a little more/better as well ;-) Thanks in advance, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeuwen@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
Hallo Jeroen, We applaud that your company is willing to contribute to OTRS. But first I'd like to point out that I guess your patch is not needed to realize the scenario you want. The Customer ID is not necessarily unique per customer user! We often make it unique for whatever in your world defines a logical set of customers, this can be a customer company, or a department if you do in-house IT, or a cost center, or such. So if you would have customer users like this: User Customer ID ====================== John D. example.com Bill O. example.com Dave K. acme.com Sue S. acme.com This way you can let people from acme.com view all tickets from acme.com without the need to patch or change anything in your OTRS setup. The only thing is that you need to find an attibute in LDAP that is the same for all customers that belong to one company (or 'partner'). Would this work for you? -- ((enjoy)) Michiel Beijen Senior Consultant Follow me on Twitter: @otrsnl [https://twitter.com/otrsnl] OTRS BV Schipholweg 103 2316 XC Leiden The Netherlands T: +31 71 8200 255 F: +31 71 8200 254 I: http://www.otrs.com GET OTRS::ITSM 2.0 NOW - including the brand new change management module! It's the only ITIL® V3 compatible open-source IT Service Management solution certified by PinkVERIFY worldwide! - http://bit.ly/dv4CJF
Hi there,
My name is Jeroen van Meeuwen, and I'm relatively new to OTRS.
I wanted to acquire some feedback on the following scenario, since I didn't seem to able to simply deploy it using current OTRS functionality.
Kolab Systems AG is the vendor for Kolab Groupware solutions, and as such mostly supports it's customers through a Partner channel system. In a nutshell, Partners help the customer and Kolab Systems helps the partners.
Long story short, these Parters (to us) are Customer Companies, and so inherently we want all employees of a partner to have all tickets logged by any other employee of that partner be available in their customer interface.
Since we are using a centralized LDAP backend for both agents and customer authentication, it seems that the proper solution suggested in the OTRS documentation, is to make one or the other LDAP attribute represent a list of "CustomerIDs", and use it to attach such attribute to a single customer LDAP entry.
However, considering we need this to be a full mesh, the administrative overhead would be enormous.
Since, also, this is a business related effort, we can safely assume that partner employees all have the same domain name space for their email addresses. Ergo, employee1@company.com is very likely to work for the same company as employee2@company.com.
I've implemented the following functionality;
In otrs/Kernel/System/CustomerUser.pm, instead of populating the CustomerIDs the user also has access to through a list of CustomerIDs from an LDAP attribute, I use the @company.com part of the email address and simply find other people also using @company.com (and stuff those email addresses in the @CustomerIDs list).
Now, the implementation I've done is simple, dirty and quick (patch attached). However, since the application may help many more organizations, and since Kolab Systems is a very much FOSS-minded company, they are willing to let me work on this with you.
That is, of course, if you find it sufficiently interesting to have this developed a little more/better as well ;-)
Thanks in advance,
--------------------------------------------------------------------- OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
NEW! ENTERPRISE SUBSCRIPTION - Get more information NOW! http://www.otrs.com/en/support/enterprise-subscription/
Michiel Beijen wrote:
Hallo Jeroen,
We applaud that your company is willing to contribute to OTRS.
Cheers!
But first I'd like to point out that I guess your patch is not needed to realize the scenario you want. The Customer ID is not necessarily unique per customer user! We often make it unique for whatever in your world defines a logical set of customers, this can be a customer company, or a department if you do in-house IT, or a cost center, or such.
So if you would have customer users like this:
User Customer ID ====================== John D. example.com Bill O. example.com Dave K. acme.com Sue S. acme.com
This way you can let people from acme.com view all tickets from acme.com without the need to patch or change anything in your OTRS setup. The only thing is that you need to find an attibute in LDAP that is the same for all customers that belong to one company (or 'partner').
This would work, most definitely. It would associate all users with one or the other Customer ID, which I suppose serves our scenario very well; from the perspective of OTRS. My question is, however, where the Customer ID accounting goes. Given that the customer users come from LDAP, I'm assuming their Customer ID must also come from LDAP? One possible future scenario in the Kolab Systems case could be that we provide the infrastructure for partner @partner.com to support customer @customer.com. I would add the cn=partner-partner.com LDAP group as a member to LDAP group cn=customer-customer.com. Such scenario, I think, pretty much represents the flexibility OTRS allows for now, but, in my opinion, with far less overhead. Please let me know what you think, I'd appreciate ;-) -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeuwen@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
On wo, 2010-06-23 at 13:47 +0200, Jeroen van Meeuwen (Kolab Systems) wrote:
My question is, however, where the Customer ID accounting goes. Given that the customer users come from LDAP, I'm assuming their Customer ID must also come from LDAP?
One possible future scenario in the Kolab Systems case could be that we provide the infrastructure for partner @partner.com to support customer @customer.com. I would add the cn=partner-partner.com LDAP group as a member to LDAP group cn=customer-customer.com.
Hey! This was not in your initial e-mail, there you just mentioned that customers working for a partner should be able to see all tickets from that particular partner. In the use case you described now, where a partner needs access to all tickets of customers of that partner, I guess OTRS could need some improvement indeed. Right now the process would be that you create a field that holds the different customer id's in the LDAP. This field would then need to be manually administered. http://doc.otrs.org/2.4/en/html/x1813.html#multi-customer-ids-ldap I think that it would be cleaner if OTRS were able to read the contents for the 'customer_ids' field from LDAP permission groups. Adding and removing LDAP users from groups is easier, cleaner and better maintainable than editing a text field manually. Would that help? -- Mike
Michiel Beijen wrote:
On wo, 2010-06-23 at 13:47 +0200, Jeroen van Meeuwen (Kolab Systems) wrote:
One possible future scenario in the Kolab Systems case could be that we provide the infrastructure for partner @partner.com to support customer @customer.com. I would add the cn=partner-partner.com LDAP group as a member to LDAP group cn=customer-customer.com.
Hey! This was not in your initial e-mail, there you just mentioned that customers working for a partner should be able to see all tickets from that particular partner.
Apologies, I was pondering this still while plowing through the vast amount of other settings.
In the use case you described now, where a partner needs access to all tickets of customers of that partner, I guess OTRS could need some improvement indeed. Right now the process would be that you create a field that holds the different customer id's in the LDAP. This field would then need to be manually administered.
http://doc.otrs.org/2.4/en/html/x1813.html#multi-customer-ids-ldap
I think that it would be cleaner if OTRS were able to read the contents for the 'customer_ids' field from LDAP permission groups. Adding and removing LDAP users from groups is easier, cleaner and better maintainable than editing a text field manually.
Would that help?
Yes, that would help very much. I'm thinking I could send a sane patch for the following logic: - Search a Groups OU (or BaseDN) for a LDAP::AccessAttr matching an expression based on the LDAP::UserAttr and current user login unique value, which gives us a list of groups the user is a member of, - Iterate over the list of groups, mapping all members of each group back to a user LDAP entry, and pushing any groups found back onto the stack[1], - get the customerID from the list of user entries - push these CustomerIDs onto, well, @CustomerIDs - return; Does such make sense as a first implementation? I might be able to look into caching later on. Of course, it goes without saying that this functionality should be made opt- in, and it shall probably not have to change normal OTRS behaviour in any way. [1] In cases where uniqueMember attributes contain a DN, this is very easy. -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeuwen@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08
Hi Jeroen, On 23.06.2010, at 16:03, Jeroen van Meeuwen (Kolab Systems) wrote:
In the use case you described now, where a partner needs access to all tickets of customers of that partner, I guess OTRS could need some improvement indeed. Right now the process would be that you create a field that holds the different customer id's in the LDAP. This field would then need to be manually administered.
http://doc.otrs.org/2.4/en/html/x1813.html#multi-customer-ids-ldap
I think that it would be cleaner if OTRS were able to read the contents for the 'customer_ids' field from LDAP permission groups. Adding and removing LDAP users from groups is easier, cleaner and better maintainable than editing a text field manually.
Would that help?
Yes, that would help very much.
I'm thinking I could send a sane patch for the following logic:
- Search a Groups OU (or BaseDN) for a LDAP::AccessAttr matching an expression based on the LDAP::UserAttr and current user login unique value, which gives us a list of groups the user is a member of,
- Iterate over the list of groups, mapping all members of each group back to a user LDAP entry, and pushing any groups found back onto the stack[1],
- get the customerID from the list of user entries
- push these CustomerIDs onto, well, @CustomerIDs
- return;
Does such make sense as a first implementation? I might be able to look into caching later on.
YES it does! :) I'm surprised to get so good discussions on the list! :)
Jeroen van Meeuwen Senior Engineer, Kolab Systems AG
-Martin
participants (3)
-
Jeroen van Meeuwen (Kolab Systems) -
Martin Edenhofer -
Michiel Beijen