Proxied Authentication in SSO Setups with Common OSS. Open Identity Summit 2015 Prof. Dr. René Peinl Berlin,

Transcription

1 Proxied Authentication in SSO Setups with Common OSS Open Identity Summit 2015 Prof. Dr. René Peinl Berlin,

2 Agenda 1 Use case / context 2 Challenge and ideal solution 3 Analysis of established SSO protocols 4 Analysis of use cases and involved systems 5 Conclusion and outlook 2

3 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/ /2016

4 SCHub system architecture nginx End-user Applications Liferay Nuxeo OX App Suite Middleware / Supporting Services Camunda BPM ElasticSearch Shindig CAS Backend Dovecot Postfix MySQL Galera / XtraDB Cluster CEPH neo4j Open LDAP Infrastructure Docker OpenStack + KVM Mesos + Marathon Univention Corporate Server

5 SCHub communication flows Connections to/from CAS and LDAP ommitted for clarity 5

6 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 s in Dovecot via IMAP ** from OX * Content Management Interoperability Services ** Internet Mail Access Protocol 6

7 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

8 Ideal solution 8

9 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

10 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

11 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 * Central Authentication Service, Jasig / Apero 11

12 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

13 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

14 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

15 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

16 Conclusion and outlook 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! 16

17 Please do SSO right from the beginning! Hof University Alfons-Goppel-Platz Hof, Germany Prof. Dr. René Peinl Head of research group systems integration Teaching area: Web architecture Phone Fax [email protected]