Single Sign On (SSO) Services with Free/Open Source Software

SSO Services with Free/Open
Source Software
Experience Sharing on JASIG CAS and Hydra
OpenSuSE Asia 2017 - University of Tokyo Electro & Communication
tonny.adhi@ui.ac.id / tonny@peentar.com - 20171022

Outline
● Short Introduction
● Understanding Single Sign On - Security Aspects
● Single Sign On @ Universitas Indonesia (University of
Indonesia)
● Single Sign On @ Peentar
● Things not Covered for Later Workshop
2

Short Introduction
● Tonny Adhi Sabastian
○ Universitas Indonesia ( www.ui.ac.id )
■ System Engineer ( 2011 - 2014 )
■ Chief of Network Administrator ( 2014 - Now )
■ Volunteer System Administrator of kambing.ui.ac.id
( Indonesia’s national F/OSS mirror service ) ( 2009 - now )
■ Part Time Lecturer at Faculty of Computer Science
● Subject : Distributed System, System Programming, Open
Source Software Development
3

Short Introduction
● Tonny Adhi Sabastian
○ Peentar ( www.peentar.id )
■ DevOps Chief (2015 - Now)
● Newly established startup in Indonesia
● Focusing on IoT, User Platform and E-Health through our
Omni Channel system
4

Understanding SSO and Its Security Aspects
5

Single Sign On 101
● In short, Single Sign On (SSO) occurs
when a user login into one application
and then signed in into other
applications automatically, regardless
of the platform, technology, or domain
where this user came from.
( https://auth0.com/docs/sso/current )
● On the contrary, Single Sign Out
occurs when a user logout into one
application, and then automatically
logout from other application.
● Example : Google Account Platform
6

Single Sign On Flow [1]
● Most SSO mechanism involved on
several parties :
○ User who owns a credential
○ Identity Provider (IDP) who
handles authentication ; but
sometimes also handles
authorization and auditing
○ Requesting Apps, as the consumer
of Identity Provider.
7

Single Sign On Flow [2]
Steps on SSO Authentication :
1. User access an apps , protected by SSO
system
2. Apps gives user a redirection to IDP site
3. User access the IDP site with his / her
credential
4. IDP site gives user access right and
several other attributes for application
access
5. User has signed in to the apps with his /
her access right and attributes
8

Single Sign On Account Backend
IDP is the major component of SSO System. It
can store and retrieve credential and also
access attributes from multiple backend, such
as :
● Directory Services ( OpenLDAP , Active
Directory )
● SQL Database
● External Service Provider
○ Google Account
○ OpenID
○ Pre-defined Web Services
9

SSO Security Aspects
There are some security benefits when we
implemented SSO System on our
organization :
● SSO prevent credential theft on the
application, as long as the apps used SSO
protected authentication
● SSO prevent authentication session
leak, because IDP holds your
authentication session
Note : SSO won’t protect you on credential
theft caused by malware, social engineering,
or keylogging . 10

F/OSS SSO Implementation
Some F/OSS SSO Implementation :
● Apereo JASIG CAS - used at Universitas Indonesia
( https://apereo.github.io/cas/5.1.x/index.html )
○ JASIG stands for Java in Administration Special Interest
Group
○ CAS stands for Central Authentication Service
○ Apache License 2.0
● ORY Hydra - used at peentar.id ; Apache License 2.0
( https://github.com/ory/hydra )
● Shibboleth ( https://www.shibboleth.net/ ) ; Apache License 2.0
● WSO2 Identity Server ( http://wso2.com/ ) ; Apache License
2.0
11

Single Sign On @ Universitas Indonesia (UI)
12

UI Short Profile (2017) [1]
Short Profile of University of Indonesia ( www.ui.ac.id ) :
● Established in 1849 by the Dutch Colonial
Government as School for Javanese Doctor
● Currently, it have more than 47000 students from
Undergraduate and Graduate Studies
● More than 6000 staffs
● 14 Faculties, 1 Vocational School, 2 Interdisciplinary
Graduate Schools
● More than 227 study programs
● Location: Jakarta and Depok, Indonesia
○ Jakarta : 9.4 Hectare
○ Depok : 320 Hectare
13

UI Short Profile (2017) [2]
F/OSS at University of Indonesia :
● Most of our solution are built on top of Free/Open
Source Software
● We believe that collaborative works on F/OSS are
easy to enhanced and adopting new things
compare than a closed proprietary ecosystem
● No benevolent dictator from proprietary ecosystem
for us ( no vendor dictatorship )
● We are maintaining one of national F/OSS
repository server ( kambing.ui.ac.id )
14

Road to Single Sign On [1]
● UI started to use OpenLDAP as credential provider
for students and staff during 2000s.
○ Single Account but authentication jungle
○ Every apps had to built their own Auth Services
to OpenLDAP. This will cause credential leakage
risk
● 2010 - 2012
○ Exploring SSO solution with JASIG CAS 3.x
○ Deploy Single Sign On Services on sso.ui.ac.id
using JASIG CAS 3.4.x. JASIG CAS provide you
with customizable Authentication Portal
○ Using OpenLDAP as credential source
15

Road to Single Sign On [2]
● 2013 - 2016
○ Update to JASIG CAS 3.5.x
○ Widely used on UI Apps and Infrastructure such as
Internet Access, Scholarship Application System,
Journal Access Proxy, Microsoft Office 365, etc
○ Handle several hundreds authentication per second
during peak hours ( 9AM - 4PM)
○ Develop Guest Account Credential as Auth Backend
using Drupal ( sso.ui.ac.id/account/ )
○ Develop additional login attributes provider based
on REST Web Services
● 2017
○ Plan for backend refactoring and update to CAS 5.x
16

UI CAS Stack & Architecture
● UI JASIG CAS Stack
○ JASIG CAS 3.5.2
○ Tomcat 7
○ Java 8
○ Debian Jessie
○ Attribute Resolution and Authentication Handler
■ OpenLDAP Auth Handler
■ SQL Based Auth Handler - Using Drupal as frontend
and MySQL as DB Source
■ Custom REST Based Service ( services.ui.ac.id / UI
Middleware )
● Why ? Some Apps need in depth attribute
checking, such as Student Enrolled and Payment
Status
17
Source : https://apereo.github.io/cas/5.1.x/planning/Architecture.html

CAS Deployment
● Steps for deploying CAS Server
○ Requirement Installation : Tomcat 7, Apache Maven or Gradle Build System, Java 7 or
Java 8, and SQL Database for Ticket Registry ( PostgreSQL recommended )
○ Compile CAS source code using Apache Maven or Gradle in order to build WAR Overlay
○ Deploy CAS WAR Overlay on your Tomcat Server
○ Configure your CAS server connection to Identity Database and other Attribute Provider
via $CAS_ROOT_DIR/WEB_INF/deployerConfigContext.xml
○ Register CAS Apps who used CAS Services at your CAS server via
$CAS_ROOT_DIR/WEB_INF/servicesRegistry.conf
○ Secure your Apps and Client connection to CAS Server using HTTPS Proxy. I recommend
to deploy Nginx in front of your Tomcat
18

CAS Protocol [1]
● CAS is a HTTP Based Authentication and Authorization Protocol, based on ticketing
mechanism.
● CAS involved a two components on authentication :
○ CAS Server, deploy alongside JASIG CAS Installation
○ CAS Client , protect the CAS applications and retrieve the identity of the granted users
from the CAS server. It embedded within application who use CAS Protocol for Single
Sign On
○ CAS Client library is implemented in most of programming language, such as Python,
PHP, .NET, Golang, etc
● CAS Ticket :
○ TGT - Ticket Granting Ticket , stored in the TGC cookie, represents a SSO session for a
user.
○ ST - Service Ticket , transmitted as a GET parameter in urls, stands for the access
granted by the CAS server to the CASified application for a specific user. 19

CAS Protocol [2]
Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html
20

CAS Protocol [3]
21

CAS Protocol [4]
22

Registering a Service to CAS Server
● This method was tested on CAS 3.5.x using JSON Based Services Registry
○ CAS Support other Services Registry too, such as YAML Based Services
○ Services Registry is kept at $CAS_ROOT_DIR/WEB_INF/servicesRegistry.conf
○ We must registered every CAS consumer services on this file
● CAS Services Registry contains several important elements :
○ serviceID
○ list of allowedAttributes
○ Enable / Disable Flag
● Example UI HotSpot WiFi Access Services ( *.gw.hotspot.ui.ac.id )
23

Peentar Short Profile
● Peentar is an Indonesian startup, focusing on development of
User and Enterprise Platform for Internet of Things and
E-Health
● Our team was established in 2015, currently we have more
than 30 skillful engineer on IoT, E-Health, System Platform,
DevOps, and UX.
● Currently, there are three line of products that we develop :
○ IoT Services and SDK for Vehicle Tracking and Status
Reporting
○ Omnichannel Engine, seamless transaction between
commerce channel, currently especially for E-Health
○ Peentar Integrated Engine and User Platform
25

Peentar Federated Login [1]
● For our User Platform, we are developing a Federated Login capabilities .
○ Example of known Federated Login are Google Apps Platform , Microsoft Office 365, or
EDUROAM for Universities and Research Network
○ If our user have their own Identity Provider or Identity Database, we can integrated it to
our system seamlessly. For example, I can use my university account (
tonny.adhi@ui.ac.id ) as Peentar Account in the future
● Federated Login means we have built or own Single Sign On stack.
○ Single Sign On Server, supporting OAuth2 protocol with OpenID , ORY Hydra (
sso.peentar.id )
○ Peentar Identity Provider, Consent Apps and Single Sign On Portal , built on top Ruby on
Rails and PostgreSQL
■ ORY Hydra don’t give you an Authentication Portal, so you have to built by
yourself
26

● Deploying Hydra
○ There is a manual and tutorial provided on here [
https://ory.gitbooks.io/hydra/content/tutorial.html ]
○ Basically it can be summarized ( but not detailed ) on these steps :
■ Prepare a PostgreSQL Database Server
■ Download or Compile ORY Hydra from source. ORY Hydra is written on Go.
■ Do a database migration
● $./hydra migrate sql [ DB_USER:DB_PASS@DB_SERVER_URL/DB_NAME ]
■ First Time Server Initialization
● $./hydra host
● It will produce several important token for your server operation, such as System
Secret, First OAuth Client ID and First OAuth Client Secret.
● Write down all of these tokens on hydra.yml file. It will be used on your server startup
● Deploy HTTPS Termination in front of your Hydra Installation (Nginx)
27

● Deploying Hydra (Cont’d)
○ Set and built Consent Apps. It will be used for your OAuth2 Transaction (token
exchanging between OAuth2 Client and SSO Services).
○ Create an host for hydra client management. This host must be a different host from
hydra server.
■ Run hydra client
■ It will ask you the URL of Hydra Server , First OAuth Client ID and First OAuth
Client Secret which you already obtained from previous step
○ Create a pair of Public and Private Key on Hydra. This key pair will be used for OAuth
Token validation and signing.
○ Hydra is using JWT ( JSON Web Token ; RFC7517) for validating and signing
authorization token .
○ Create Consent Apps ID and Secret. It will be used by your Consent Apps
○ Create as much as Apps ID and Secret for your other Apps. 28

Hydra OAuth2 Flow
Source : https://ory.gitbooks.io/hydra/content/oauth2.html#consent-flow 29

Not Covered
● JASIG CAS & Hydra Detailed Deployment
● Adding and Removing Backend Services for Attribute Resolution
● Howto Integrate / Use CAS and Hydra Authentication to your service
● JASIG CAS Tuning - Hydra
● Next : I will set a workshop on other chances
30

Single Sign On (SSO) Services with Free/Open Source Software

More Related Content

What's hot (7)

Similar to Single Sign On (SSO) Services with Free/Open Source Software (20)

More from Tonny Adhi Sabastian (13)

Recently uploaded (20)

Single Sign On (SSO) Services with Free/Open Source Software