1. CLASSe PROJECT: IMPROVING SSO IN THE CLOUD Alejandro Pérez (alex@um.es)alex@um.es Rafael Marín (rafa@um.es)rafa@um.es Gabriel López (gabilm@um.es),gabilm@um.es TNC 2015, Porto June 17 th, 2015 1

2. Introduction 2 CLASSe (Cloud-ABFAB Federation Services in eduroam) Objectives: 1.Enabling GÉANT users to access cloud services (OpenStack) using ABFAB technologies 2.Improving the SSO user experience 3.Designing solutions to support Virtual Organizations (VOs)

3. ABFAB 3 IETF WG –Application Bridging for Federated Access Beyond web Federated identity for Internet protocols not based on HTTP –E.g: SMTP, SSH or NFS

4. ABFAB 4 Key components: –EU  Wants to access a service –RP  Provides the service –IdP  Authenticates the EU and provides authorization information to the RP

5. ABFAB 5 Core technology  GSS-EAP (RFC 7055): –GSS-API  Access control to the service –EAP  User authentication –RADIUS  Federation –SAML  Authorization information Moonshot  Reference implementation

6. CLASSe 6 Allowing GÉANT users to access cloud services using ABFAB technologies –Modified OpenStack to support for ABFAB authentication (using Moonshot) –And to translate SAML attributes to OpenStack attributes Benefits: –Any member of the GÉANT community can access the cloud service without requiring the creation of a new account As a result of the project, official support for Moonshot is being included in OpenStack

7. CLASSe 7 Objectives: 1.Enabling GÉANT users to access cloud services (OpenStack) using ABFAB technologies 2.Improving the SSO user experience 3.Designing solutions to support Virtual Organizations (VOs)

8. Single Sign-On (SSO) 8 Objectives: –Prompt the EU for credentials once at the beginning of the session –The rest of accesses to different RPs do not require introducing the credentials again Two different models, that we have called: –Traditional SSO –Real SSO

9. Single Sign-On (SSO) 9 Traditional SSO –Secure storage of credentials on the EU’s device E.g.: Gnome-keyring, Window’s credential manager, Firefox credential manager... –Software agent takes care of the automatic selection and provision of credentials  Does not require any specific SSO mechanism at protocol level  A complete authentication process is performed for each different access  high resource utilization Moonshot uses this model  Identity Selector

10. Single Sign-On (SSO) 10 Real SSO –Provides the EU with some sort of authentication token –The token is used to speed up subsequent authentication processes E.g.: Kerberos, SAML, OpenID…  The authentication processes typically consists on a single round trip  low resource utilization  Requires support at protocol level

11. CLASSe 11 Improving the SSO user experience –Optimize how traditional SSO is performed in Moonshot –Introduce real SSO in ABFAB

12. Optimizing traditional SSO in Moonshot 12 Typical Moonshot EAP methods are TTLS and PEAP –~7 round-trips to complete –Several asymmetric cryptography operations (e.g.: DH exchange) We have implemented support for TLS-resumption –Store TLS session state in the EU’s device after first authentication –Use it to speed up authentication in subsequent accesses –Authentication is reduced to 3 round-trips with no DH

13. Performance analysis 13 We have measured: –Total amount of time to complete the access to the cloud service (including authentication, authorization, OpenStack operations…) –Total amount of data exchanged between the entities during the whole access process –Amount of time spent in the AAA infrastructure –Amount of data exchanged in the AAA infrastructure

14. Performance analysis 14 MoonshotTTLS-resumption Total time2727 ms2056 ms (-24%) AAA time567 ms231 ms (-59%) Total data (bytes)64395 bytes47958 bytes (-25%) AAA data (bytes)6450 bytes2420 bytes (-62%)

15. Introducing real SSO in ABFAB 15 ERP (EAP Re-authentication Protocol) –Standard mechanism for fast re- authentication in EAP –Needs minor adaptations in GSS-EAP Documented in draft-perez-abfab-wg-arch-erp-00 –Reduces the number of round-trips to 1 Less amount of traffic and time spent in the AAA infrastructure –Avoid contacting the IdP for intra-domain SSO

16. Performance analysis 16 MoonshotERP (inter-domain)ERP (intra-domain) Total time2727 ms1779 ms (-34%)1659 ms (-39%) AAA time567 ms76 ms (-86%)0 ms (-100%) Total data (bytes)64395 bytes43682 bytes (-32%)41929 bytes (-35%) AAA data (bytes)6450 bytes1645 bytes (-75%)0 bytes (-100%)

17. Main contributions to the IETF 17 ERP extensions for GSS-EAP –Describes how to support ERP in the GSS-EAP mechanism (RFC 7055) –Personal draft: draft-perez-abfab-wg-arch-erp-00 Fragmentation support for RADIUS –Defines how to send RADIUS packets over the 4096 limit –Recently published as RFC 7499 A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML –Defines how to transport SAML over RADIUS –Active collaboration and editorship –WG document: draft-ietf-abfab-aaa-saml

18. Summary 18 Improving traditional SSO in Moonshot with TLS- resumption –Solution at implementation level  Moonshot –Provides substantial reductions on the overload on the AAA infrastructure (59%) Introducing real SSO in ABFAB with ERP –Solution at specification level  ABFAB –Provides further reductions on the overload on the AAA infrastructure (86%-100%) ABFAB-enabled applications do not need of any change

19. Next steps 19 Continue moving forward our ERP proposal for real SSO on the ABFAB WG Try to push ERP support into FreeRADIUS

20. 20 Thank you for your attention