Proxied Authentication in SSO Setups with Common OSS Open Identity Summit 2015 Prof. Dr. René Peinl Berlin, 10.11.2015
Proxied Authentication in SSO Setups with Common OSS
Open Identity Summit 2015
Prof. Dr. René Peinl Berlin, 10.11.2015
2
Use case / context
Challenge and ideal solution
Analysis of established SSO protocols
Analysis of use cases and involved systems
Conclusion and outlook
1
2
3
4
5
Agenda
Project: Social Collaboration Hub (SCHub)
Goal: Establishing an integrated infrastructure for
effective support of team collaboration, esp. for
knowledge intensive tasks and regionally distributed employees
• direct support for knowledge and business processes
• From a user‘s perspective, a unified intranet
with continuous support for working tasks
without breaches in the workflow should arise.
Solution: Integration of Open Source Software from the areas
portal, document management (DMS), groupware and
business process management (BPM) 10/2014 - 09/2016
SCHub system architecture
Middleware / Supporting Services
CAS
nginx
Backend
OpenLDAP
MySQL Galera / XtraDB Cluster Postfix
Dovecot
CEPH
End-user Applications
Nuxeo OX App Suite Liferay
Infrastructure
Univention Corporate Server
OpenStack + KVM
Docker
Mesos + Marathon
neo4j
ElasticSearch Camunda BPM Shindig
Challenge
Securely authenticate from one server system
to communicate with another server system
in the name of the user logged on to the first system
Use cases
1. Access to the ECMS Nuxeo via CMIS* from Liferay and OX
2. Triggering workflows in Camunda from Liferay, Nuxeo and OX
3. Storing activities in Shindig from Liferay, Nuxeo, OX and Camunda
4. Accessing emails in Dovecot via IMAP** from OX
6
*Content Management Interoperability Services **Internet Mail Access Protocol
Terms
• No common terminology to describe the challenge
• double hop issue (Microsoft)
– Not widely accepted term
• delegated authentication (SAML)
– Also used for delegating authentication to an external system
• Impersonation
– Server 1 impersonates the user, but mainly used to describe attacks
• proxy authentication
– HTTP proxy that authenticates, vs app that does API calls
=> proxied authentication in order to avoid wrong associations
7
SSO protocols
• OAuth 2.0
– „Authorization code grant“ flow seems well suited for the scenario
– Existing implementations assume authorization server (SSO
system) and resource server (server system 2) are identical
– Supplement on „bearer token usage“ mentions our scenario
– Problem really solved in successor OpenID connect
• SAML 2.0
– Delegated SAML authentication [1] is describing the scenario
– Technologies used are specified in addendum to SAML 2.0 spec.
– Not fully supported by CAS 4.1, new in Nuxeo 7.4, established in
Liferay, but delegated authentication still questionable
9
SSO protocols
• Kerberos
– Not tailored for the Web-based world but still suitable
– Supports the scenario with ticket granting tickets
– Two open source Kerberos v5 implementations for Linux
• MIT Kerberos Server
• Heimdall
– CAS, Nuxeo and Liferay support Kerberos, CAS only with AD
10
Proprietary solutions
• CAS* Proxy Authentication
– Uses similar mechanism like Kerberos
– Server 1 can request proxy granting ticket (PGT)
– Afterwards use PGT to request proxy tickets for server 2
– Server 2 must validate whole chain included in proxy ticket
• CAS* ClearPass
– Password replay feature of CAS
– Server 1 can request the current user‘s password
– Authentication against server 2 with username/password
– Less secure, not nice, but effective and efficient
11
*Central Authentication Service, Jasig / Apero
Use case CMIS
• All systems with CMIS interface in the project use Apache Chemistry
• Chemistry supports OAuth 2.0 since version 0.13 (04/2015)
• Nuxeo is still using version 0.12 in their latest version 7.4 (09/2015)
• Liferay explicitly states that only user/password auth is supported
although Liferay is already using Chemistry version 0.13
• Decision
– Evaluate usage of CAS ClearPass
– Encourage Liferay to support OAuth 2.0
– Encourage Chemistry community to update support to OID connect
12
Use case workflows
• Camunda only supports basic http authentication
• Authentication is exchangable
• Multiple candidates would make sense
• OAuth 2.0 or even better OpenID connect seem the right way to go
• Decision
– Write an own wrapper around Camunda
– Evaluate usage of RESTeasy and RESTlet for this wrapper
– Use OAuth 2.0 with bearer tokens for authentication
until CAS supports OpenID connect
13
Use case OpenSocial
• OpenSocial 2.x uses OAuth 2.0
as primary authentication mechanism
• Apache Shindig comes with an OAuth 2.0 service provider
• For the project, Apache Shindig was „CASified“
• Special challenge: systems have to authenticate if user is not logged in
(e.g. for long running processes)
• Decision
– Use 2-legged OAuth 2.0 for storing activities in Shindig
14
Use case IMAP
• Dovecot is used as an IMAP Server
• Dovecot does only support Kerberos
• In large scale installations like Strato,
communication between OX Server and Dovecot
uses a master password to authenticate
• Decision
– Since our SaaS scenario of the project is similar to the Strato
hosting, we will also use the master password feature
15
Conclusion and outlook
16
• The described scenario has some pitfalls and is costly to implement
• Although solved in theory, it is still demanding in practice
• As often, new protocols like OAuth are less sophisticated than older
protocols like Kerberos, who are seen as heavy weight
• OpenID connect is a promising specification
• SSO with the Web frontend is easy,
but hard for end-to-end solutions
• Use libraries that do authentication for you!
Hof University
Alfons-Goppel-Platz 1
95028 Hof, Germany
www.hof-university.de
Phone +49 9281 409-3000
Fax +49 9281 409-4000
Please do SSO right from the beginning!
Prof. Dr. René Peinl
Head of research group systems integration
Teaching area: Web architecture