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

SCHub communication flows

5

Connections to/from CAS and LDAP ommitted for clarity

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

Ideal solution

8

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

rene.peinl@hof-university.de

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