Canarie Federated Non Web Signon
-
Upload
chris-phillips -
Category
Education
-
view
617 -
download
3
Transcript of Canarie Federated Non Web Signon
CAF Technology Overview for Federated Non-Web Sign-on
Aug 2011 Chris Phillips – [email protected]
Agenda
• Review understanding of Canada Lightsource & challenges
• Background about CAF• Overview of available Technologies• Demo?• Review various deployment scenarios
2
What is the Access Federation?
• A collection of trust frameworks for the Canadian electronic identity ecosystem – Targets the challenge of secure access to 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
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
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
What about outside the web?
7
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
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
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
Contrasting the Approaches
Shibboleth+ECP Moonshot/ABFAB
Password Treatment Userid/Password pair seen & transits outside classic Shibboleth infrastructure boundaries
Userid/Password seen & transits through RADIUS infrastructure
Home Institution Discovery
Somehow preconfigured either via user or by static configuration in proxy & proxy under an infrastructure providers control
Userid contains hint to institution so it is present in credential and implicitly discoverable on usage (e.g. <id>@realm.ca)
Attribute Exchange Exchanged via SAML2, aggregated via standard Shibboleth fashion (DB/LDAP/static values etc)
Exposed via GSS API, delivered via RADIUS pack/unpack technique, aggregated from many potential sources
‘Breadth’ of accounts ECP configuration or end user intervention drives breadth of coverage
If RADIUS uses eduroam, entire set of federation accounts are available
Environment Used in Mobile devices, IMAP clients, very targetted and controlled infrastructures. Unix machines with a preconfigured Id Provider.
Unix shell environments, rich clients, anywhere that the GSS-API exists.
12
Live@edu Federated Identity
Live@eduService Management Portal
WS-Federation/WS-Trust
Windows Live ID
Outlook LiveWindows Live
Services(e.g. SkyDrive)
Configure & Manage
Federated Identity
ADFS 2.0Active
Directory
Fabrikam.edu
Non-AD Directory
Contoso.edu
Shibboleth 2.x
SAML 2.0
Other Rich Clients
Microsoft Federation Gateway
(Windows Live ID)Login to Windows Live ID
& SAML 2.0 Enhanced Client/Proxy (ECP)
Web Clients
Web Clients
Email rich client support requires the Shibboleth IdP ECP Extension
Email Rich Clients
Email Rich Clients
OpenJump
14
15
ABFAB/Moonshot
16
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 eduroam and Shib so 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
Logical View
18
Sequence Diagram
19
Editable WebSequence Diagram: http://bit.ly/CAF-Moonshot-WSD
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
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, ldap objectclass 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
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
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
Technical Slides
24
eduroam
25
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
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).
Secure Wireless – 802.1X
April 27th 2010 Canada eduroam Slide 28
1) Negotiate Authentication Method EAP-PEAPv0-MSCHAPv2
2) Certificate Validation Prevents “man-in-the-middle” attack
3) Establish Secure Tunnel Prevents eavesdropping
secure.wireless.ubc.ca
4) Perform authentication through tunnel Using MSCHAPv2
5) Authentication successful Establish encryption, connect to net
Wireless Encryption Established
6) Client acquires IP address (DHCP)
ssid: ubcsecure
id: jdoe
Eduroam - Roaming User
April 27th 2010 Canada eduroam Slide 29
ssid: eduroam
realm: ubc.ca
realm: sfu.ca
realm: ca
Institution Servers
Federation Server
1) Negotiate EAP type EAP-TTLS-PAP2) Outer Request Validate cert.3) Inner Request PAP – through tunnel – secure!
4) Success Establish encryption.
Cert: eduroam.sfu.ca
Establish TLS tunnel
Connect to network
Eduroam – International Roaming
April 27th 2010 Canada eduroam Slide 30
realm: ubc.ca
realm: sfu.ca
realm: ca
Confederation Server
Federation Server
realm: mit.edu
realm: edu
realm: ucla.edu
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
Shibboleth
32
Material
• Past Presentations:– This presentation builds on CANHEIT 2010:
• Prezi on Building federated applications:– http://bit.ly/fedapps
33
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
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
Rightsize Your Information Sharing
Wireless
Log in, sh
are nothing
Log in, sh
are Opaque ID
SAML as conduit for Information release
ExternalWebsite
personal-izationis desired
Log in, sh
are NetID
InternalWebsite
personal-izationis desired
linkageelsewheredesired
Log in, sh
are NetID
+attr.
InternalWebsite
personal-izationis desired
linkageelsewheredesired
Data needed(ghosted)
Unified View Leverages Infrastructure(aka internal/nested/layered trust groups)
The ‘Federation’
Local FedIdp SP
SP
Local FedIdp SP
SP Idp
SP
Special Interest Trust Groups
IdpIdp
Idp
• The Federation. sets POP/FOP requirements. • Serves as the base inherited elements for local
or SITG activity to enhance or build upon• Most efficient way to insure least effort for
SP/IdP to participate any way they want, including promotion to eduGain
• Local Fed. can have need their own isolated SP/IdPs
• Encourages organic growth on path to full Federation involvement.
• The Federation enables SITG to form their own special metadata sourced from the core metadata
SPSP
SP
SP Idp
Higher Assurance