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

id: [email protected]

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

id: [email protected]

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

For more info, please contact

[email protected]

Twitter: @teamktown

38