Federations in HigherEd and Privacy

1. Federations in HigherEd and Privacy Klaas Wierenga TNO, August 31, 2009

2. Agenda • Identity federations – what and why • Privacy requirements for Identity federations • Two wide-spread examples of federated access in HigherEd • Network access: eduroam • Application access: SAML (Shibboleth)

3. IDENTITY FEDERATIONS – WHAT AND WHY

4. Identity

5. Common Issues for Users • Credential Management • Too many login ids and password combinations to remember or worse they are all the same • Using lowest strength credentials (passwords) for high value transactions • Ease of Use • Remembering which credentials to use with a site • Filling in the same information for registration forms at different sites • User Concern over personal information • Concern about the information collected by sites and what happens to the data after collection • Protection from impersonation and identity theft • Phishing • How does a user really know they are at the site they think they are? • Issue over vetting process of user’s identity • User proves identity by ownership of email address

6. Service Provider Identity Provider Relationship between entities Authenticates User (Principal) Uses services Trusts Trust is the foundation of any security model. Trust is the expression between entities that one entity will believe statements (claims) made by another entity; it is based on evidence – history, experience, contracts, etc. – and risk tolerance.

7. Federated Identity Management • Management and use of identity information across organization boundaries • Allows organizations to participate in inter-organization authentication and authorization • Architecture consists of • Service Providers (SP) • Identity Providers (IdP) common trust Federation (Home) Organization Resource(s) Source: SWITCH

8. Without Federated Identity Management University A • Tedious user registration at all resources • Unreliable and outdated user data at resources • Different login processes • Many different passwords • Many resources not protected due to difficulties • Often IP-based authorization • Costly implementation of inter-institutional access Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Source: SWITCH Credentials

9. With Federated Identity Management University A Federated Identity Managment • No user registration and user data maintenance at resource needed • Single login process for the users • Many new resources available for the users • Enlarged user communities for resources • Authorization independent of location • Efficient implementation of inter-institutional access Student Admin Web Mail e-Learning Library B e-Journals Literature DB University C Research DB e-Learning User Administration Authentication Authorization Resource Source: SWITCH Credentials

10. PRIVACY

11. Personal data • In the context of digital identity privacy is mainly about the protection of personal data • EU Data Protection Directive (Directive 95/46/EC) • Transparency • Legitimate purpose • Proportionality • Important concept: Personally Identifiable Information (PII) • Information that can be used to uniquely identify, contact, or locate a single person or can be used with other sources to uniquely identify a single individual

12. Identity Providers • Must identify which services are necessary for education/research • Must consider whether personally identifiable information is necessary for those services, or whether anonymous identifiers or attributes are sufficient; • Must inform users what information will be released to which service providers, for what purpose(s). • May release that necessary personally identifiable information to those services; • May seek users’ informed, free consent to release personal data to other services that are not necessary for education/research • Must inform users what information will be released to which service providers, for what purpose(s); • Must maintain records of individuals who have consented; • Must allow consent to be withdrawn at any time; • Must only release personal information where consent is currently in effect. • Should have a data processor/data controller agreement with all service providers to whom personally identifiable data is released. • Must ensure adequate protection of any data released to services outside the European Economic Area.

13. Service Provider • Must consider whether personally identifiable information is necessary for their service, or whether anonymous identifiers or attributes can be used; • Should obtain that information from home organisations; • Should have a data processor/data controller agreement with all home organisations from whom personally identifiable data is obtained; • If no such agreement is in place, must inform users what personal information will be obtained, by which service providers, for what purpose(s). • May request personal information from users • Must inform users what information will be released to which service providers, for what purpose(s); • Must ensure that users who do not provide information are not unreasonably disadvantaged; • Must maintain records of individuals who have consented; • Must allow consent to be withdrawn at any time; • Must cease processing data when consent is withdrawn

14. Pseudonymous identifiers • E.g. IP address, ePTID, … • These allow recognition of a repeat visitor • But not identification of a living individual • Must treat them as personal data (Art 29 WP) • Unless you know you can’t/won’t obtain linking information • Almost always personal data in ISP/IdP’shands • They need to make the link in cases of misuse • SP can perhaps treat them as non-personal data • Must not ask the user for any potentially linking information • Must know IdP can’t/won’t disclose their linking information • Agreement with IdP is a good way to do this • Unilateral statement from IdP may be enough • Identifier must conceal user’s identity (e.g. by hashing) • NB Law is currently unclear and likely to change

15. Potentially conflicting interests

16. FEDERATED NETWORK ACCESS (EDUROAM)

17. The goal of eduroam • “open your laptop and be online” • To build an interoperable, scalable and secure authentication infrastructure that will be used all over the world enabling seamless sharing of network resources

18. Eduroam architecture • Security based on 802.1X+EAP (WPA/WPA2) • Protection of credentials • Different authentication mechanisms possible by using EAP (Extensible Authentication prototcol) • Roaming based on RADIUS proxying • Remote Authentication Dial In User Service • Transport-protocol for authentication information • Trust fabric based on: • Technical: RADIUS hierarchy • Policy: Documents/contracts that define the responsibilities of user, institution, NREN and the eduroam federation • Authentication by home institution, authorisation by visited institution

19. eduroam Supplicant Authenticator (AP or switch) RADIUS server University A RADIUS server University B User DB User DB Guest pete@university_b.ac.uk SURFnet Commercial VLAN Employee VLAN Central RADIUS Proxy server Student VLAN • Trust based on RADIUS plus policy documents • 802.1X • EAP for mutual authentication and privacy protection signalling data Source: SURFnet

20. eduroam status > 600 Service Providers Approx. 10 million users • Canada member since June 2008 • Trials in Latin-America, US

21. Privacy • Mutual authentication • Encryption on the radio network • Tunneled EAP • Anonymous outer-id • Policies • authN at home • Not exposing credentials to 3d parties • Future: • Chargable User Identity to carry Pseudonym • Peer to peer trust using RadSec

22. Tunneled authentication RADIUS + TLS Channel(s) RADIUS@visited RADIUS@home eduroam hierarchy Access Point Id Repository • EAP-tunnel terminates @home • Inner identity: username@realm • Outer identity: anonymous@realm

23. FEDERATED APPLICATION ACCESS (SAML)

24. Federations in education • Authentication (login) • Establish trust • Common Language (Security Assertion Markup Language, SAML) • Policy for information flow • Attributes, roles • Privacy support • Share across institutional borders • Standardized integration • Security solution • Well-known integration path • Multi vendor support

25. SAML Source: SWITCH

26. Privacy • eduPerson Targeted ID • Pseudonymous identifier that is service specific • Mutual authentication • Encryption of authentication traffic • Authn at home • Not exposing credentials to third parties • Policies • User consent

27. Not logged In

28. WAYF

29. Log In

30. Consent

31. Logged In

32. More info • eduroam: • http://www.eduroam.org • SAML: • http://www.oasis-open.org/committees/security/ • EU Privacy • http://ec.europa.eu/justice_home/fsj/privacy/index_en.htm