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. networkName@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.phillips@canarie.camailto:chris.phillips@canarie.ca | W: 613.943.5370 |GPG: 0x0380811D
LinkedIn: http://bit.ly/CPhillipsLinkedIn
From: