Hi Chris, Thank you very much for your generous response. It pushed me to get a basic understanding on how it works. Sorry for responding with a delay. I sent out the initial email just before leaving on Friday and was on mobile devices until now.
I have 2000+ customer accounts across 400+ companies. The cheapest solution for me would be to hack OTRS to achieve SP-like functionality against my custom portal, which would act like an IdP. I would at least try this if I knew there's some combination of Apache authentication plugins + OTRS authentication modules that can support it at a non-laughable security level (e.g. an Apache plugin that can perform a server side query against a web service or database to get user information and then fill it in for OTRS). The Shibboleth path is certainly a solution with a much better long term ROI but the upfront cost is unknown and scary. I would need to not only get familiar with how Shibboleth works (e.g. there are issues with logging out / switching session across domains that require in-depth tweaking; see the end of https://www.youtube.com/watch?v=SmT8X5iEX5Q) but I would also need to develop at least one plugin that queries my custom portal for identity information (user management will be performed in a custom manner via the new custom portal and I can't rely on some standard LDAP / AD source for identities). QUESTION(s): You mentioned you used the "Shibboleth Service Provider plugin for Apache" but with what OTRS authentication module (HTTPBasicAuth?)? Did you have to resort to writing any custom code in OTRS to get it to work? Thanks, Bogdan On 2 October 2015 at 18:04, Chris Phillips <chris.phill...@canarie.ca> wrote: > We have an instance of OTRS (current version:4.0.5) and have implemented > Federated SSO based on SAML2 and the Shibboleth Service Provider plugin for > Apache. > > Initial setup and effort was about 3-6hrs on an OTRS instance with a > small set of users. We use it for agents only at the moment, but CAN use > it for OTRS customers. > > The strategic element for enabling Federated SSO for customers is to use > scoped usernames (e.g. networkn...@domain.com). > Our sign ins originate from our Shibboleth IdP as well as other customers > who also have IdPs. We use the Canadian Access Federation(CAF) as our > aggregate (full disclosure: We operate CAF) > > > In your case, you have a more complex situation and likely own more of the > infrastructure than you expect. > > You have both a Portal and an OTRS instance to sign in and need to > harmonize usernames across both systems. > > This means that you would not only need to install and configure the > federation components for OTRS, but your portal as well. Not a small task, > but not insurmountable either. > It does double your migration/implementation project effort to not just be > OTRS, but OTRS+Portal. > > There are a few ways to do this and be strategic about it. If you are > really a 'federation of one IdP to your small set of service providers', > then you can possibly stand up an Identity Provider pointing to your Portal > database and declare those as the primary or singular identity and then use > those to sign into OTRS and create the necessary records for the customers. > This way you have full control over all pieces of the environment. > > There is another aspect which is the provisioning part of this model. > AFAIK, there is no 'autocreate' for accounts signing into OTRS — and you > may not want to either. This means you need to create the necessary OTRS > customer, OTRS contact, and then assign necessary permissions to the > account for each one and any other SLA/Service Catalogue elements. > I'm assuming that your portal identities are handled automatically as > needed. > > If you are looking for technologies to assist with doing any of this, I > recommend using the Shibboleth components for the Service Providers and the > Identity Providers(www.shibboleth.net). Creating the federation metadata > is not too hard (if you know what you are doing) for the trust set of your > one idp and 2 services (portal+OTRS). > Other tools you could consider are SimpleSAMLPHP and ADFS if you are more > aligned with .NET and claims. AAIedu.hr used SimpleSAMLPHP if I recall > correctly. > You can still use ADFS with SAML2 tools but it may be a more difficult > path and need to be sufficiently knowledgable about how to implement. > > Your 'expense' is not really the OTRS part but your migration to a new > authentication/authorization model between BOTH services. > However, once implemented and migrated it would be maintainable using > standard practices — especially if you have a addressed a good way to > manage the provisioning of the OTRS environment. > You may be small enough that this is manually achievable, but from > experience you will quickly tire of the manual part and may want to pursue > automation very quickly. > > How big is your user base BTW? > > Chris. > > ___________________________________________________________________________________________ > Chris Phillips > Technical Architect, Canadian Access Federation | CANARIE| > chris.phill...@canarie.ca | W: 613.943.5370 |GPG: 0x0380811D > LinkedIn: http://bit.ly/CPhillipsLinkedIn > > > > > > From: <otrs-boun...@otrs.org> on behalf of Bogdan Iosif < > bogdan.io...@gmail.com> > Reply-To: "User questions and discussions about OTRS." <otrs@otrs.org> > Date: Friday, October 2, 2015 at 8:16 AM > To: "User questions and discussions about OTRS." <otrs@otrs.org> > Subject: [otrs] SSO / Federated Identity > > Hi, > > I use v3.3 with the default db backend for customer login and need to > integrate it with an in-house-built customer experience portal (view > reports/bills/marketing materials/etc.). > > The customer should login only once (in the portal) and then seamlessly > jump between the portal and OTRS. The OTRS authentication & session > lifetime should be settled transparently behind the scenes between the > systems (i.e. log out / switch id from portal => same in OTRS). > > QUESTION: Is there an authentication module in OTRS or in Apache which > could be tweaked to create this integration against our new portal? > > Thanks, > Bogdan > > P.S: > > OTRS' manual points to Kernel::System::Auth::HTTPBasicAuth which seems to > rely on Apache doing the authentication. I know nothing about this > approach but if someone would tell me that it supports log out / switch id > in OTRS when customer does that in our portal, I would look into it. > > I also found this http://developer.aaiedu.hr/faq/11.html ~ solution for > v3.0 that integrates with a custom-built PHP SAML provider. I could modify > it to use a [custom] NET provider but I would end up with a very expensive > solution. > > > --------------------------------------------------------------------- > OTRS mailing list: otrs - Webpage: http://otrs.org/ > Archive: http://lists.otrs.org/pipermail/otrs > To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs >
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
