CLASSe PROJECT: IMPROVING SSO
IN THE CLOUD
Alejandro Pérez ([email protected])
Rafael Marín ([email protected])
Gabriel López ([email protected]),
TNC 2015, Porto
June 17th, 2015
1
Introduction
• 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)
2
ABFAB
• IETF WG
– Application Bridging for Federated Access
Beyond web
• Federated identity for Internet protocols
not based on HTTP
– E.g: SMTP, SSH or NFS
3
ABFAB
• Core technology 
GSS-EAP (RFC 7055):
• Moonshot  Reference
implementation
RADIUS/SAML
– GSS-API  Access
control to the service
– EAP  User
authentication
– RADIUS Federation
– SAML  Authorization
information
IdP
EAP
GSS-API
EU
RP
5
CLASSe
• 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
6
CLASSe
• 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)
7
Single Sign-On (SSO)
• 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
9
Single Sign-On (SSO)
• 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
10
CLASSe
• Improving the SSO user experience
– Optimize how traditional SSO is performed in
Moonshot
– Introduce real SSO in ABFAB
11
Optimizing traditional SSO in Moonshot
• 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
12
Performance analysis
• 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
13
Performance analysis
Moonshot
TTLS-resumption
Total time
2727 ms
2056 ms (-24%)
AAA time
567 ms
231 ms (-59%)
Total data (bytes)
64395 bytes
47958 bytes (-25%)
AAA data (bytes)
6450 bytes
2420 bytes (-62%)
3000
2750
2500
2250
2000
1750
1500
Non-AAA time (ms)
1250
1000
AAA time (ms)
750
500
250
0
Moonshot
TTLS-resumption
70000
65000
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
Non-AAA data (bytes)
AAA data (bytes)
Moonshot
TTLS-resumption
14
Introducing real SSO in ABFAB
• ERP (EAP Re-authentication Protocol)
– Standard mechanism for fast reauthentication 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
15
Performance analysis
Moonshot
ERP (inter-domain)
ERP (intra-domain)
Total time
2727 ms
1779 ms (-34%)
1659 ms (-39%)
AAA time
567 ms
76 ms (-86%)
0 ms (-100%)
Total data (bytes)
64395 bytes
43682 bytes (-32%)
41929 bytes (-35%)
AAA data (bytes)
6450 bytes
1645 bytes (-75%)
0 bytes (-100%)
3000
2750
2500
2250
2000
1750
1500
1250
1000
750
500
250
0
Non-AAA time (ms)
AAA time (ms)
Moonshot
ERP (interdomain)
ERP (intradomain)
70000
65000
60000
55000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
Non-AAA data (bytes)
AAA data (bytes)
Moonshot
ERP (interdomain)
ERP (intradomain)
16
Main contributions to the IETF
• 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
17
Summary
• Improving traditional SSO in Moonshot with TLSresumption
– 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
18
Next steps
• Continue moving forward our ERP
proposal for real SSO on the ABFAB WG
• Try to push ERP support into FreeRADIUS
19
Thank you for your attention
20