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

Presented at openSUSE Asia 2017, Tokyo Japan
Talk oultine :
- SSO 101
- JASIG CAS
- Hydra

Transcript

1. 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
2. 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
3. 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
4. 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
5. Understanding SSO and Its Security Aspects 5
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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
12. Single Sign On @ Universitas Indonesia (UI) 12
13. 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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. CAS Protocol [2] Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html 20
21. CAS Protocol [3] Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html 21
22. CAS Protocol [4] Source : https://apereo.github.io/cas/5.1.x/protocol/CAS-Protocol.html 22
23. 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
24. Single Sign On @ Peentar 24
25. 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
26. 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
27. 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
28. 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
29. Hydra OAuth2 Flow Source : https://ory.gitbooks.io/hydra/content/oauth2.html#consent-flow 29
30. 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
31. Q & A 31