1. CAF Technology Overview for Federated Non-Web Sign-on Aug 2011 Chris Phillips –chris.phillips@canarie.ca

2. Agenda Review understanding of Canada Lightsource& challenges Background about CAF Overview of available Technologies Demo? Review various deployment scenarios 2

3. Canada’s Digital Infrastructure: CANARIE Why CANARIE? To improve the effectiveness of research in Canada

4. What is the Access Federation? A collection of trust frameworks for the Canadian electronic identity ecosystem Targets the challenge of secure accessto the network and to online resources Home for different flavours of trust frameworks Recognizes autonomy of its participants Participants in the ecosystem The Federation Operator (CANARIE) Identity Providers (IdP) offer authentication/authorization of their identities Service Provider (SP) who offer services . End Users 4

5. Access Federation Services eduRoam a wireless access authentication trust framework based on the RADIUS protocol and 802.1x. Shibboleth an online authentication and authorization trust framework based on the SAML protocol Services are implementations of a specific trust framework 5

6. Eligibility for Access Federation Must be CANARIE member to use service Currently over 32 participants, including all of the larger universities in Canada. Eligible participants include: higher education institutions public research institutions sponsored service providers Participation for other CANARIE members being examined. Entitlement will be on service by service requirements due to different needs per service. 6

7. What about outside the web? 7

8. The Challenge (as we hear it…) How can I leverage a federated identity ecosystem safely, securely, and reliably to deliver my services, even if my services are not delivered via the web? 8

9. The Who & The What Who is your audience or client and how diverse a group are they? What are you trying to deliver or improve? 9

10. Worksheet to help Answer the Q. 10

11. Federated Identity Approaches Shibboleth + ECP (Enhanced Client Proxy) Examples: Microsoft Live@EDU OpenJump GIS Moonshot/ABFAB(Application Bridging for Federated Access Beyond web) No live examples yet (Oct 2012 installfest in London, England) An emerging IETF standard Blend of RADIUS+Shib 11

12. Contrasting the Approaches 12

13. Live@edu Federated Identity Configure & Manage Federated Identity Live@edu Service Management Portal Outlook Live Windows Live Services (e.g. SkyDrive) Microsoft Federation Gateway (Windows Live ID) Windows Live ID Login to Windows Live ID Web Clients Web Clients & SAML 2.0 Enhanced Client/Proxy (ECP) SAML 2.0 WS-Federation/WS-Trust Fabrikam.edu Contoso.edu Email Rich Clients Email Rich Clients Active Directory Non-AD Directory ADFS 2.0 Shibboleth 2.x Email rich client support requires the Shibboleth IdP ECP Extension Other Rich Clients

14. OpenJump 14

15. 15

16. ABFAB/Moonshot 16

17. Proposed Deployment Can be any computing infrastructure, looking for candidates Proposed requirements to participate Member of one or more federations trust fabrics (RADIUS &/or SAML) Canada manages both eduroamand Shibso these would be our choices On the target site: Has administrative control over the target to log into (unix box) Has deployed local Moonshot enhancements to said unit (a patched SSHd and Moonshot enhanced GSS libraries) Manages a RADIUS server for their site that is connected to eduroam and is a SAML SP in the Shib Fed. runs Moonshot enhancements Has made necessary configurations in each of the pieces to allow access Has provisioned the necessary information to an acount to permit sign in 17

18. Logical View 18

19. Sequence Diagram 19 EditableWebSequence Diagram: http://bit.ly/CAF-Moonshot-WSD

20. Implementation Questions How does the local environment interact with Moonshot? GSS exposes the data via attribute release from querying it: How does this map to local environment variables? implicit trust that the attributes in those variables are trustworthy & immutable via GSS API call – is this ok? How is the GSS API call secured against a multi-homed multi-user environment? If on same system, can I query for various GSS sessions and walk the users on the system? (doubtful, but want to ask to verify) Assumption is GSS takes care of partitioning users. 20

21. Implementation Questions How do the central components interact with Moonshot? See a need for a formalized schema map to benefit 80% and let 20% extend. Most cost effective is set one standard (based on input) ‘internationally’ with ability to extend Does this style of schema exist elsewhere (e.g. GridShib toolkit?) Various origin datasources are in play so centralized schema in different formats (e.g. 3NF tables for SQL, ldapobjectclass definitions, and SAML profiles would be great to level the playing field. Thoughts on how long/big/worthwhile this is and how repetitive it will be? Thoughts on how elements go from ‘core’ from the extensions? (aka Governance?) 21

22. Total Cost of Ownership How will the account provisioning and maintenance work? Representing a federated cred in a remote environment…how? How will the policy decision on access work? If at the ‘edge’ or end points, need a way to manage mass deployment (>1000’s of systems – think EC2) OR centralize this somehow Need to harmonize the way to deal with schema and consistent view of data across RADIUS & SAML & DB & LDAP…thoughts? Complex is ok, as long as automation can prevail, but what skills will be required to keep the lights on for this software ecosystem? 22

23. Possible Limitations RADIUS attribute passing is limited to 253 bytes per attribute My understanding is that Moonshot takes care of packing/unpacking long attributes over RADIUS protocol Not an issue, but as a more rich attribute definition is built out, there could be large profiles (think XML & x509 certs BASE64’d into this) which may suffer over RADIUS’ UDP. Should we be concerned? Updated: RADIUS attributes cannot exceed 4096 in their entirety. Could pose some challenges… 23

24. Technical Slides 24

25. eduroam 25

26. Use Case – Wireless Access Without eduRoam User arrives, needs to get onto wireless Needs to talk to IT staff to get credential in system created and a password set User waits for account User uses known password, signs into wireless When user is complete, IT should be notified to delete account and terminate access (right?) IT deletes account(right?) Done With eduRoam User arrives, needs to get onto wireless, has eduRoam enabled ID Open laptop User is authenticated to home system and is online Done 26

27. How does eduroam work? 802.1X - to authenticate clients before allowing access to the network EAP framework – with secure EAP methods to protect user credentials RADIUS - authentication server infrastructure RADIUS proxying – to route authentication requests to a users home institution Separate IP address space – treated as external to institution (compliance with service agreements, etc) End Users have standard internet access with as few filters as possible (if any at all).

28. Secure Wireless – 802.1X April 27th 2010 Canada eduroam Slide 28 Wireless Encryption Established secure.wireless.ubc.ca ssid:ubcsecure id:jdoe 1)Negotiate Authentication Method EAP-PEAPv0-MSCHAPv2 2)Certificate Validation Prevents “man-in-the-middle” attack 3)Establish Secure Tunnel Prevents eavesdropping Using MSCHAPv2 4)Perform authentication through tunnel 5)Authentication successful Establish encryption, connect to net 6)Client acquires IP address (DHCP)

29. Eduroam - Roaming User April 27th 2010 Canada eduroam Slide 29 Federation Server realm: ca ssid:eduroam Cert: eduroam.sfu.ca Institution Servers id: joe@sfu.ca realm: ubc.ca realm: sfu.ca 1) Negotiate EAP type EAP-TTLS-PAP 2) Outer Request Validate cert. Establish TLS tunnel PAP – through tunnel – secure! 3) Inner Request 4) Success Connect to network Establish encryption.

30. Eduroam – International Roaming April 27th 2010 Canada eduroam Slide 30 Confederation Server Federation Server realm: ca realm: edu id: pam@mit.edu realm: ubc.ca realm: sfu.ca realm: mit.edu realm: ucla.edu

31. Reciprocity - Hallmark of eduroam Eduroam is about you treating guest credentials how you would like to be treated: Just think about what you would like when you travel: No filtered connections No traffic shaping Public IP address (where possible) NAT is not necessarily appropriate, but if you already private IP folks now, probably works out ok. 31

32. Shibboleth 32

33. Material Past Presentations: This presentation builds on CANHEIT 2010: Prezi on Building federated applications: http://bit.ly/fedapps 33

34. Use Case – New Employee Access to Online Resources Without Shibboleth User arrives, needs to have access to web resource for Active Directory Twiki.canarie.ca Staff.canarie.ca Collaborate.canarie.ca Shared online resources in 3rd party wiki Needs to talk to staff for each service to get credential in each system created and a password set User waits for account for each service User uses known password, signs into each service and sets a password When user leaves the organization, each service should be notified to delete account and terminate access everywhere (right?) Each service deletes account(right?) Done With Shibboleth User arrives, needs to have access to web resource for Active Directory Twiki.canarie.ca Staff.canarie.ca Collaborate.canarie.ca Shared online resources in 3rd party wiki IT staff creates central account and assigns privileges to access resources centrally. User waits for account User changes password and all services rely on this password. When user leaves the organization, this one account should be notified for deletion (right?) Done 34

35. Shib Value Proposition Game changer for integration effort with shib ready services Reduces integration from customization to configuration Avoid weeks of custom project integration and then maintenance until, well, forever  Lowers cost of doing business – do better with less. Establishes a centralized policy enforcement point and easier auditability For new work, establishes publicly accepted framework to implement to & not your own homegrown framework 35

36. Rightsize Your Information Sharing Log in, share NetID+attr. Log in, share Opaque ID Log in, share NetID Log in, share nothing Wireless External Website personal- ization is desired Internal Website personal- ization is desired linkage elsewhere desired Internal Website personal- ization is desired linkage elsewhere desired Data needed (ghosted)‏ SAML as conduit for Information release

38. Serves as the base inherited elements for local or SITG activity to enhance or build upon

39. Most efficient way to insure least effort for SP/IdP to participate any way they want, including promotion to eduGain

40. Local Fed. can haveneed their own isolated SP/IdPs

41. Encourages organic growth on path to full Federation involvement.

42. The Federation enables SITG to form their own special metadata sourced from the core metadataSP Idp Higher Assurance Local Fed Local Fed Idp SP Idp SP SP SP Idp

43. For more info, please contact Chris.phillips@canarie.ca Twitter: @teamktown 38