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<mailto:chris.phill...@canarie.ca> | W: 613.943.5370 |GPG: 0x0380811D LinkedIn: http://bit.ly/CPhillipsLinkedIn From: <otrs-boun...@otrs.org<mailto:otrs-boun...@otrs.org>> on behalf of Bogdan Iosif <bogdan.io...@gmail.com<mailto:bogdan.io...@gmail.com>> Reply-To: "User questions and discussions about OTRS." <otrs@otrs.org<mailto:otrs@otrs.org>> Date: Friday, October 2, 2015 at 8:16 AM To: "User questions and discussions about OTRS." <otrs@otrs.org<mailto: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
