Your SlideShare is downloading. ×
Canarie Federated Non Web Signon
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Canarie Federated Non Web Signon

588
views

Published on

Published in: Education, Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
588
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • CANARIE is part of Canada’s national digital infrastructure that drives improved research effectiveness in Canada– a tremendous Canadian asset that supports knowledge creation and innovation CANARIE staff provide the network expertise and programs to enhance the effectiveness of research in CanadaThis expertise ensures connectivity to Canadian hubs of innovation and research – over 1000 institutions are connected and over 140,000 researchers rely on CANARIEIt is made up of 19,000 km of fibre optic cable – about half the circumference of the earthIt links Canadian researchers to their peers in 80 countriesCANARIE offers state-of-the-art speed – 100 G – on our core corridors. You could download every single iTunes movie – 2500 of them – in 7 seconds on our 100G networkCANARIE receives funding from Industry Canada in five year “tranches” – our current mandate expires in March 2012 – since CANARIE’s creation in 1993, $470M has been invested
  • Currently over 30 participants, including all of the larger universities in Canada.
  • A common security model could be leveraged as well, but this would be very difficult due the differences in the requirements. Some work could progress. “Science Studio” will hook into a centralized security solution when that security solution becomes available.
  • One service is good, but many using the same ‘infrastructure’ is better:Common approach to governance & oversightGenerally coordinating with with same point of contactsBuild both for traversal up and downwards
  • Transcript

    • 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
    • 37. Unified View Leverages Infrastructure(aka internal/nested/layered trust groups)
      The ‘Federation’
      SP
      Idp
      Idp
      SP
      Idp
      SP
      Special Interest Trust Groups
      SP
      • The Federation. sets POP/FOP requirements.
      • 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 metadata
      SP
      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

    ×