SSO Services with Free/Open Source Software Experience Sharing on JASIG CAS and Hydra OpenSuSE Asia 2017 - University of Tokyo Electro & Communication [email protected] / [email protected] - 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] Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html 21 

CAS Protocol [4] Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html 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 

Single Sign On @ Peentar 24 

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 ( [email protected] ) 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 

Peentar Federated Login [2] ● 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 

Peentar Federated Login [3] ● 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 

Q & A 31