multilateral federation: a primer
TRANSCRIPT
www.incommon.org
Multilateral Federation: A Primer Tom Scavo March 31, 2014
www.incommon.org
Who Am I?
• Welcome! • A little bit about me:
Tom Scavo Operations Manager, InCommon.org Employed by Internet2.edu Graduate degrees in Statistics (UWyo), Mathematics (UWyo), Computer & Information Science (UOregon) Worked in Education (esp. Higher Education) my entire life
• Twitter: @trscavo • Email: [email protected]
www.incommon.org
Training Overview
• Three-part training overview: 1. Part 1: Federated Identity
2. Part 2: Multilateral Federation—Basic Concepts
3. Part 3: Multilateral Federation—Future Directions
• Hands-on training exercises are scattered throughout
• To access the training exercises and obtain the presentation slides: https://spaces.internet2.edu/x/ZIvFAg
www.incommon.org
Getting Started
• Training Exercises are sprinkled throughout. You will need: – A networked laptop (or other device)
– A bash shell
– A web browser
• To minimize your dependency on the training room network, you can download metadata ahead of time by following the instructions here:
• Getting Started: https://spaces.internet2.edu/x/tYPPAg
www.incommon.org
Part 1 Federated Identity
www.incommon.org
What is Federated Identity?
• The goal of federated identity is the sharing of user identifiers and attributes across security domains – The process whereby two parties federate identity is sometimes
called federation (with a small “f”), not to be confused with the notion of a “Federation” (with a capital “F”) described in Part 2
• A primary motivation for federated identity is the desire to minimize the number of authentication tokens (e.g., passwords) that the user and the relying party must manage
• As a practical consequence, federated login is distributed away from the relying party (towards an Identity Provider—but I’m getting ahead of myself!)
www.incommon.org
Federation is Hard! • Read Google’s notes on why migration to OpenID is hard
– “the need for websites to choose the list of identity providers (and potentially attribute & service providers) that they want to trust/support”
• Susan Landau’s paper is insightful: http://journals.uic.edu/ojs/index.php/fm/article/view/4254/3340
– Tussle 1: Who gets to collect transactional data? – Tussle 2: Who sets the rules of authentication? – Tussle 3: What happens when things go wrong? – Tussle 4: Who gains and who loses from interoperability?
• Bonneau et al. outline a framework for comparing web authentication technology: The Quest to Replace Passwords
– Three groups of benefits: usability, deployability, security – On the following three slides, we use the framework of Bonneau et al. to
compare “Password” with “Federated Password”
www.incommon.org
www.incommon.org
www.incommon.org
www.incommon.org
Federated SSO Protocols
• AFAIK there are only a handful of federated single sign-on (SSO) protocols that meet our needs: 1. SAML V1.1 Web Browser SSO (2001) 2. OpenID 2.0 (2005) 3. SAML V2.0 Web Browser SSO (2005) 4. OpenID Connect (2014?)
• At this point, SAML V1.1 Web Browser SSO and OpenID 2.0 are legacy protocols
• SAML V2.0 Web Browser SSO is the incumbent • OpenID Connect is leading-edge technology
www.incommon.org
OpenID Connect • OpenID Connect is brand new and all the rage
– OpenID Foundation spec ratified on February 26, 2014 – Technology stack: HTTPS, REST, JSON, JOSE – SP-initiated browser flow – Non-browser flow (e.g., on mobile devices) – Message-level signing and encryption – Session management and single logout
• Aims to address all the weaknesses of SAML V2.0 Web Browser SSO
• Currently deployed in production by Google, Salesforce et al. • Open-source implementations are being developed and
tested as we speak
www.incommon.org
Security Assertion Markup Language
• The Security Assertion Markup Language (SAML) is: – An XML Schema-based markup language – A well-defined set of protocols, bindings, and profiles:
• Authentication Request Protocol • HTTP-Redirect and HTTP-POST Bindings • Web Browser SSO Profile
• The primary contribution of the SAML standard is: – SAML V2.0 Web Browser SSO – “Do one thing, and do it better than anyone else”
(DollarShaveClub.com)
• A secondary contribution (but almost as important) is: – SAML Metadata (see Part 2)
www.incommon.org
SAML V2.0 Web Browser SSO • SAML V2.0 Web Browser SSO is mature and dominant
– OASIS spec ratified in 2005 – Technology stack: HTTPS, SOAP, XML, XML Security – SP-initiated browser flow – Message-level signing and encryption
• The SAML SSO Profile is intentionally designed to be flexible • Deployers can mix and match bindings according to their
needs • Years of deployment experience have settled on a
deployment model that has found widespread use throughout higher education
• Study the sequence diagram depicted on the following slide
www.incommon.org
www.incommon.org
SAML V2.0 Web Browser Flow • Observations:
– Three actors: Service Provider, User, Identity Provider – Somehow the Service Provider is able to discover the User’s
preferred Identity Provider – Authentication at the Identity Provider is out of scope – Both the Identity Provider and the Service Provider maintain their
own session – There are no back channels involved (although possible) – Transport-level security (i.e., TLS) is not sufficient
• See SAML 2.0 wikipedia documentation (which I wrote) for more detail
• The desired deployment model is captured in the SAML V2.0 Interoperability (saml2int) Deployment Profile
www.incommon.org
Training Exercise #1
To illustrate federated login, do the following: 1. Obtain a ProtectNetwork account
a) https://app.protectnetwork.org/registration.html
2. Access the Shibboleth wiki a) https://wiki.shibboleth.net b) Click “Login” and type “ProtectNetwork” as suggested
3. [optional] Install SAML tracer (or its cousin SSO Tracer) on Firefox and repeat the previous step a) https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/ b) https://addons.mozilla.org/En-us/firefox/addon/sso-tracer/
www.incommon.org
Federated User Experience
• Important contributions to the overall federated user experience (in temporal order): 1. IdP Discovery (SP)
2. Federated Login (IdP)
3. User Consent (IdP)
4. Error Handling (SP)
• User Consent will be illustrated in Part 3
www.incommon.org
IdP Discovery
• Assumption: There are (and will be) 1000s of IdPs in the world
• IdP Discovery can make or break your federated web app
• Four simple considerations: 1. Login link
2. Local login
3. Discovery software
4. Presentation choices and options
• See: Good and Bad Demos
• For further reading: http://discovery.refeds.org/guide/
www.incommon.org
Security and Privacy Considerations • The SP redirects the User to a trusted endpoint at the IdP
– How does the SP know the IdP’s trusted endpoint location? • The IdP signs the SAML assertion; the SP verifies the signature
– How does the SP obtain the IdP’s trusted public key?
• The IdP encrypts the SAML assertion; the SP decrypts the message – How does the IdP obtain the SP’s trusted public key?
• At a minimum, the IdP asserts a user identifier in the response (but the IdP may assert other user attributes as well)
– How does the SP know the IdP is authorized to assert a given scoped attribute (such as [email protected])?
• The IdP always asserts an authentication context (even if the SP doesn’t ask for one)
– How does the SP know the IdP is authorized to assert a given authentication context (such as InCommon Silver)?
www.incommon.org
Bilateral Metadata Exchange
• The answer to every question on the previous slide is: – Trusted Metadata (SAML or otherwise)
• The simplest form of bilateral metadata exchange (MDX): – IdP sysadmin and SP sysadmin exchange MD via email – Admins configure (static) MD into their respective deployments – Admins effectively own each other’s MD
• Drawbacks – Not secure – Not interoperable – Does not scale
• We will have much more to say about metadata in Part 2
www.incommon.org
Bilateral Metadata Exchange IdP
Bilateral MDX: Best-Case Scenario
Browser
Webapp
XML
SP
Browser
Webapp
XML
www.incommon.org
SAML Software Implementations
• Two widely deployed open-source SAML implementations: – Shibboleth – simpleSAMLphp
• To be on our radar, a SAML implementation must have a good story with respect to SAML metadata – (FWIW, the two implementations mentioned above are
recommended for use in the InCommon Federation)
• That said, there are other implementations of SAML in use: – Microsoft AD FS – PingFederate – CA SiteMinder
www.incommon.org
Shibboleth • Shibboleth is an open-source project of the
Shibboleth Consortium – Home: http://shibboleth.net/ – Docs: https://wiki.shibboleth.net/ – Mailing lists: http://shibboleth.net/community/lists.html
• Shibboleth includes a SAML IdP (Java), a SAML SP (C++ apache module), and other components
• Configuration via XML files • Shibboleth has strong metadata management capabilities for
multilateral federation • Historical note: Shibboleth began life as an Internet2
middleware project over 10 years ago, about the same time the InCommon Federation launched
www.incommon.org
SimpleSAMLphp
• SimpleSAMLphp is an open-source project of UNINETT – Home: http://simplesamlphp.org/
– Docs: http://simplesamlphp.org/docs/stable/
– Mailing lists: http://simplesamlphp.org/lists
• SimpleSAMLphp includes a SAML IdP and a SAML SP (both PHP)
• Configuration via PHP files
• SimpleSAMLphp includes a metarefresh module for automated metadata management
www.incommon.org
Part 2 Multilateral Federation: Basic Concepts
www.incommon.org
What is a Federation?
• A Federation (with a capital “F”) is a group of organizations that come together to exchange information on behalf of their users to enable on-line access to protected resources
• The primary goal of the Federation is to create and support a common framework to facilitate access to on-line resources
• Practically speaking, perhaps the most important function of the Federation is the production and distribution of trusted metadata
• Participating organizations use metadata (keys, trusted endpoints, etc.) to build out the Trust Fabric of the Federation
www.incommon.org
Federation Operating Principles
Basic operating principles of any Federation:
Trust
Interoperability
Privacy
TIP the scales in favor of Federation!
www.incommon.org
Trust
• Trust related activities of the InCommon Federation (e.g.): – Identity Federation
• Metadata registration, administration, production, distribution, and consumption
• IdP deployment strength: – enforce minimum key size (at least 2048 bits) – promote proper key handling – XML signature on assertions using SHA-256
– Certificate Service – Identity Assurance – Multifactor Authentication
www.incommon.org
Interoperability • Recommended practices lead to interoperability:
– SAML software guidelines
– SAML protocol support
– SAML deployment profile (saml2int)
– certificate migration
– attribute syntax (on-the-wire) and semantics
– federated user experience
• Standards at all levels of the technology stack permit bilateral federation but a mutually agreed upon deployment profile is essential to global interoperability
• Goal: Near-100% coverage (or penetration) is a strong requirement
www.incommon.org
Privacy • Privacy in today’s world is anything but understood, yet
privacy is fundamental to any social activity, including federation, which is social by its very nature
• All InCommon participants agree to basic privacy principles (see: Participation Agreement, section 9), not to mention FERPA
• Other aspects of the privacy issue: – We do not require IdPs to share particular attributes
– We do not store user attributes
• Indeed, since we are a full-mesh Federation, user attributes do not transit Federation servers
– We support and encourage message-based encryption
– We promote service categories that tend to encourage attribute release
www.incommon.org
Federation Deployment Models
• It’s convenient to categorize Federations based on their scope and structural deployment model: – SAML-Based Enterprise SSO
– Full-Mesh Federation
– Hub-and-Spoke Federation
• The above deployment models are building blocks
• More complex models for interfederation are possible
• For further reading: https://wiki.edugain.org/File:Options-for-Joining-eduGAIN.pdf
www.incommon.org
SAML-Based Enterprise SSO • Many enterprises apply
Federation operating principles within their own security domain
• SAML is well-suited as an Enterprise SSO system (but it has competitors in higher education, such as CAS)
• If you want to federate with external partners (and who doesn’t) SAML is probably your best choice
IdP
SP
SP
SP
www.incommon.org
High-Throughput SAML IdPs
• Is a “high-throughput” SAML IdP with many SP partners possible?
• Yes, there are numerous examples of high-throughput SAML IdPs in the wild
• Some examples of production Shibboleth IdPs: https://wiki.shibboleth.net/confluence/x/-oG3
• A deployment that focuses on 100% browser-facing SAML2 Web Browser SSO can achieve very high throughput – No SAML Artifact – No SAML Attribute Query
www.incommon.org
Full-Mesh Federation
IdP
IdP
IdP
SP
SP
SP
Think of this diagram when you hear the phrase “Trust Fabric”
www.incommon.org
Hub-and-Spoke Federation
IdP
IdP
IdP
SP
SP
SP
IdP Proxy
The simpleSAMLphp software is well suited to this deployment model
www.incommon.org
What is Multilateral Federation?
• Basically, multilateral federation is federation at scale
• For example, consider the size of the InCommon Federation (on February 9, 2014): – 438 organizations
– 1897 SAML entities • 339 IdPs; 1558 SPs
• R&E SAML Federations worldwide: – 40+ Federations
– 7000+ SAML entities
• And that’s just published entities in higher education!
www.incommon.org
SAML Metadata
• SAML metadata describes SAML entities – Primarily, Identity Providers and Service Providers
• Technologies: XML, XML Schema, XML Signature
“Metadata is the stuff that Federations are made of”
• SAML IdP deployments consume trusted SP metadata
• SAML SP deployments consume trusted IdP metadata
www.incommon.org
Metadata Registration Practice 1. Organization submits signed Participation Agreement 2. Organization is identified 3. Organizational identity is verified 4. Executive is identified 5. Executive identity is verified 6. Executive is credentialed 7. Executive provisions a Site Administrator 8. Site Administrator identity is verified 9. Site Administrator is credentialed 10. Site Administrator submits metadata 11. Registration Authority approves metadata submission 12. Key Authority signs the metadata 13. Metadata is published
www.incommon.org
Multilateral Metadata Exchange IdP
Browser
SP
Browser
XML
IdP
Browser
Webapp
SP
Browser
IdP
Browser
SP
Browser
Bro
wse
r
www.incommon.org
Training Exercise #2
• At this point, it will be instructive to download InCommon metadata and inspect its contents, either using a browser window or from a command line
• To download metadata with a browser, click the following link: – http://md.incommon.org/InCommon/InCommon-metadata.xml
• SAML metadata has content-type application/samlmetadata+xml so you will have to save the XML to a file and open it with a text editor
• Alternatively, download and analyze metadata from a command-line shell. See the Training Exercises wiki page for Getting Started and some commands for Metadata Analysis.
www.incommon.org
Metadata Trust Models
• The critical role of metadata in establishing technical trust among Federation participants
“Trusted metadata makes multilateral federation possible”
• Two metadata trust models in wide use today: 1. Explicit Key Trust Model
2. PKIX Trust Model
• We concentrate on the Explicit Key Trust Model for the remainder of this presentation
• For further reading: https://spaces.internet2.edu/x/t43NAQ
www.incommon.org
Public Key Infrastructure
• Regardless of the trust model, there are three keys of interest (listed below in increasing order of importance) in a SAML-based public key infrastructure: 1. The SP decryption key
2. The IdP signing key
3. The FedOp signing key
• The corresponding public keys constitute the so-called Trust Fabric of the Federation
www.incommon.org
Explicit Key Trust Model
• The public keys bound to certificates in metadata are trusted, not the certificates themselves
• A certificate is merely a convenient wrapper for a trusted public key
• In particular, the Explicit Key Trust Model does not depend on any so-called root certification authorities
• Entities are strongly encouraged to use long-lived, self-signed certificates, which simplify key maintenance
• For further reading: https://spaces.internet2.edu/x/boY0
www.incommon.org
Perturbations to the Trust Fabric • Events that perturb the Trust Fabric of the Federation (listed in
order of increasing disruption): 1. Changing the IdP Signing Key
• For further reading: https://spaces.internet2.edu/x/dJiKAQ 2. Changing the SP Decryption Key
• For further reading: https://spaces.internet2.edu/x/dpiKAQ 3. Changing the Metadata Signing Key
• The latter is most disruptive—a new Metadata Signing Key (MSK) essentially “reboots” the Trust Fabric of the Federation (since every deployment must bootstrap trust)
• Ideally, the MSK is an offline key and/or protected by an HSM • Note: The Metadata Signing Certificate can be re-issued (not re-keyed) with little
effect assuming metadata clients are doing the Right Thing
www.incommon.org
Metadata Consumption
• The time it takes for the Federation as a whole to recover from a perturbation to the Trust Fabric is a function of the metadata refresh behavior of Federation entities
• InCommon Federation Metadata Refresh Policy – It is strongly recommended that InCommon SPs and IdPs refresh
and verify metadata at least daily. An optimal configuration would attempt to refresh metadata every hour.
• Assuming the integrity of metadata is maintained, an optimal, automated Metadata Refresh Process provides an entity (and its partners) with maximum security, privacy, and interoperability
• For further reading: https://spaces.internet2.edu/x/JwQjAQ
www.incommon.org
Metadata Refresh Process
• Steps to deploy a secure, automated Metadata Refresh Process: 1. Choose exactly one of three Metadata Aggregates
2. Obtain an authentic copy of the Metadata Signing Certificate
3. Install and configure recommended Metadata Client Software: a. Refresh metadata at least daily (but more often if possible) b. Validate the expiration date on downloaded metadata c. Verify the XML signature on downloaded metadata
• SAML software with an integrated metadata client is highly desirable for multilateral federation
www.incommon.org
Metadata Aggregates
• A deployment chooses one of three available metadata aggregates 1. The production metadata aggregate:
http://md.incommon.org/InCommon/InCommon-metadata.xml
2. The fallback metadata aggregate: http://md.incommon.org/InCommon/InCommon-metadata-fallback.xml
3. The preview metadata aggregate: http://md.incommon.org/InCommon/InCommon-metadata-preview.xml
• Multiple aggregates allow changes to metadata to be made more quickly, easily, and safely
• The basic choice for deployers: Production or Preview? • For further reading: https://spaces.internet2.edu/x/SoG8Ag
www.incommon.org
Refresh Interval
• All deployments are strongly encouraged to refresh metadata at least daily
• If the metadata client supports HTTP Conditional GET, configure it to refresh metadata every hour
• This strategy provides maximum security, privacy, and interoperability
• In particular, this strategy provides the best protection in the event of an entity key compromise
• Clearly, a flexible SAML metadata client is nearly as important as the SAML software itself!
www.incommon.org
HTTP Conditional GET • A smart client will cache metadata and implement HTTP
Conditional GET (RFC 2616, Section 9) – In the InCommon Federation, deployments based on capable clients
are advised to refresh metadata every hour
• A conditional GET request results in either an HTTP 200 response or an HTTP 304 response – The latter response has no body content
• Two HTTP Conditional GET mechanisms: 1. Last-Modified / If-Modified-Since 2. ETag / If-None-Match
• The mechanics of HTTP Conditional GET are illustrated in the Training Exercises
• For further reading: https://spaces.internet2.edu/x/44GVAQ
www.incommon.org
Security Considerations • A secure Metadata Refresh Process must perform two critical
document-level security operations every time a metadata file is downloaded:
1. Validity Check 2. Signature Verification
• An individual metadata file has a validity period from a few days to a few weeks
– An optimal validity interval is thought to be 4 days (YMMV)
• A signed metadata file provides authenticity and integrity – Confidentiality of metadata is (intentionally) not provided
• Before the signature on a metadata file can be verified, an authentic copy of the metadata signing certificate must be obtained
• Some of the operations shown in the following slides are further illustrated in the Training Exercises
www.incommon.org
Validity Check
• SAML metadata has an expiration date, much like an X.509 certificate
• A metadata file should not be accepted if any of the following conditions are true: 1. If the metadata file does not have a validUntil XML attribute on its
root element 2. If the validUntil date on the root element is expired 3. If the validUntil date on the root element is too far into the future
• A metadata refresh process should check each of the above conditions before verifying the signature and accepting the metadata
www.incommon.org
Signature Verification
• A trusted metadata process MUST verify the XML signature on SAML metadata
• It is neither sufficient nor necessary to request the metadata via a TLS-protected HTTP connection
• Transport-level security mechanisms (e.g., TLS) provide little (if any) benefit and are not recommended in conjunction with metadata refresh – Indeed, some metadata servers do not even enable TLS
• To verify the signature on metadata, a metadata refresh process is bootstrapped with an authentic copy of the metadata signing certificate
www.incommon.org
Metadata Signing Certificate
• To bootstrap the Trust Fabric of the Federation, consumers download and configure an authentic copy of the Metadata Signing Certificate into their metadata refresh process: – # obtain an authentic copy of the metadata signing certificate – $ MD_CERT_LOCATION=https://ds.incommon.org/certs/inc-md-cert.pem – $ MD_CERT_PATH=/path/to/inc-md-cert.pem – $ /usr/bin/curl --silent $MD_CERT_LOCATION > $MD_CERT_PATH – # compute the SHA-1 fingerprint of the metadata signing certificate – $ /bin/cat $MD_CERT_PATH \ – | /usr/bin/openssl x509 -sha1 -noout -fingerprint – SHA1 Fingerprint=7D:B4:BB:28:D3:D5:C8:52:E0:80:B3:62:43:2A:AF:34:B2:A6:0E:DD
• The computed fingerprint is compared to the actual fingerprint of the certificate (obtained from a secure server via a browser)
• For further reading: https://spaces.internet2.edu/x/moHFAg
www.incommon.org
Standalone XML Security Tools • Standalone tools for XML Security:
– XmlSecTool (pure Java) – XMLSec (C library based on LibXML2 and OpenSSL)
• For example, here’s how you would use XmlSecTool to verify the signature on InCommon metadata: $ MD_LOCATION=http://md.incommon.org/InCommon/InCommon-metadata.xml
$ MD_PATH=/tmp/InCommon-metadata.xml
$ /usr/bin/curl --silent $MD_LOCATION > $MD_PATH
$ ./xmlsectool.sh --verifySignature --signatureRequired \
--certificate $MD_CERT_PATH --inFile $MD_PATH
INFO XmlSecTool - Reading XML document from file '/tmp/InCommon-metadata.xml'
INFO XmlSecTool - XML document parsed and is well-formed.
INFO XmlSecTool - XML document signature verified.
• We would rather not build a metadata refresh process from scratch, however
www.incommon.org
Metadata Client Software
• The best metadata client software is completely integrated into the SAML implementation
• Recommended metadata client software 1. Shibboleth
2. simpleSAMLphp
3. pysFEMMA (for use with Microsoft AD FS)
• Shibboleth has the best integrated metadata management facility
• For further reading: https://spaces.internet2.edu/x/QYG8Ag
www.incommon.org
Shibboleth Client Config
Refresh every hour
Validity Check
Signature Verification
www.incommon.org
Part 3 Multilateral Federation: Future Directions
www.incommon.org
Are We Done Yet?
• After completing Part 2, we can conclude that federated identity is a solved problem, right?
• Ha! My day job is protected for many years to come! • There are huge, unsolved problems looming before us:
– Penetration – Assurance – Privacy – Interfederation – Metadata Exchange Models
• We’ll touch on each of these problems in Part 3
www.incommon.org
Penetration
• From the SP’s point of view, if a user wants to access my service, but that user doesn’t have an account with a trusted IdP, what are our options?
• In other words, does the user possess a federated identity that the SP will accept in lieu of local authentication (which is basically what federation is all about)?
• Penetration (or coverage) is the probability that an arbitrary user will be able to log into the SP via a trusted IdP
• A Federation that doesn’t offer near-100% penetration isn’t likely to attract many SPs
• A phrase that captures this scenario is “Bring Your Own Identity” (BYOI)
www.incommon.org
IdP of Last Resort • Until recently, an IdP of Last Resort (sometimes called an IdP for the
Homeless) was the universally recognized answer to the penetration problem
– Note: You used an IdP of Last Resort to log into a federated web app during the Training Exercise in Part 1
• A major disadvantage of an IdP of Last Resort is that the poor user is forced to create yet another password, which contradicts a basic premise of federated identity
• For further reading: Quit peeing in the identity pool (Tim Bray)
• As an alternative to an IdP of Last Resort, we could leverage ubiquitous Social Identity (Google, e.g.) as illustrated on the next slide
www.incommon.org
OIDC RP
SAML IdP
campus-based SAML
SP
campus-based SAML
IdP
campus-based SAML
IdP
Federation Metadata
No Attribute Release Policy!
Course-Grained User Consent
Attribute Filter
Business Associate
Agreement
GAE Local Login
SAML SP
OIDC OP
Google Gateway
Powered by Cirrus Identity and Internet2
www.incommon.org
Social Identity • The Google Gateway illustrated on the previous slide:
– Has been in production since October 2013 – Taps into Social Identity without reinventing the Federation – Suggests that Multilateral Federation is protocol agnostic and does not
depend on metadata format (XML, JSON, etc.)
• The Google Gateway works with GAE, GAB, or GAG but there’s nothing magic about Google
– In principle, the same Social2SAML gateway technology works with Salesforce or any other SaaS/PaaS that has the required interfaces (SAML and OIDC)
• Two distinct use cases: 1. A centralized Google Gateway for Research & Scholarship SPs 2. An enterprise Google Gateway solution for the "long tail" of Federation
IdPs
www.incommon.org
Training Exercise #3
To illustrate federated login with Google, do the following:
1. Access the Internet2 Spaces wiki a) https://spaces.internet2.edu
b) Click “Login”, type “Google Sign In”, and press “Select”
2. [optional] Install SAML tracer (or its cousin SSO Tracer) on Firefox and repeat the previous step a) https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/
b) https://addons.mozilla.org/En-us/firefox/addon/sso-tracer/
www.incommon.org
User Consent
www.incommon.org
Assurance • Recall that federation necessarily introduces an untrusted 3rd party,
the Identity Provider • As a Federation matures, Service Providers quite naturally seek to
distinguish various classes of Identity Providers based on criteria such as:
– Identity Proofing – Authentication Strength
• This leads to the notion of levels of assurance but as of yet there is no widespread agreement on requirements or semantics
– Both SAML and OpenID Connect have protocol mechanisms for communicating LoA
• One thing’s for sure, multifactor authentication is definitely gaining traction
www.incommon.org
Distributed Multifactor Authentication • Although interest in multifactor is high, it will be quite some time
before a significant fraction of our 339 Identity Providers deploy it • In the meantime, Service Providers who care can protect
themselves using off-the-shelf SAML IdP Proxy technology • For instance, the Multifactor IdP Proxy is a SAML-to-SAML gateway
that implements distributed multifactor authentication – The Multifactor IdP Proxy is integrated with the Duo Security mobile-based
authentication solution
• A staging instance of Multifactor IdP Proxy is being tested now – This instance is integrated with Duo Security, built (by Cirrus Identity) using
simpleSAMLphp, and deployed in the cloud (AWS)
• A sequence diagram that shows how a user (MRAO) logs into a service (Comodo CM) using a password (Internet2 IdP) and a mobile device (InCommon IdP Proxy) via a cloud-based multifactor service (Duo Service)
www.incommon.org
OIDC RP
SAML IdP
campus-based SAML
SP
campus-based SAML
IdP
campus-based SAML
IdP
Multifactor IdP Proxy
GAE Local Login
SAML SP
OIDC OP
Google Gateway
SAML SP
SAML IdP
Federation Metadata MF
Service Powered by Cirrus Identity, Duo Security, and Internet2
www.incommon.org
Privacy • The Google Gateway shown earlier has thrust privacy into the
limelight – For further reading:
Google admits data mining student emails in its free education apps – Snowden of course shattered previously held notions of privacy as well
• In US higher education, privacy is heavily influenced by FERPA, which was mentioned in passing in Part 2
• Primarily due to FERPA, the release of user attributes from Identity Providers to Service Providers is the exception rather than the rule
• To help reconcile the conflict between privacy and attribute release, the notion of a Service Category was introduced
• The first such category is the Research & Scholarship Service Category, described briefly on the following slides
www.incommon.org
Research & Scholarship Category
• The primary goal of the Research & Scholarship Service Category is to streamline attribute release
• The Research & Scholarship Category – “Candidates for the Research and Scholarship (R&S) Category
are Service Providers that support research and scholarship as an essential component”
• Browse the official list of InCommon R&S IdPs and SPs: https://incommon.org/federation/info/all-sp-categories.html
• An international standardization effort is underway: – The REFEDs R&S Category specification
www.incommon.org
Research & Scholarship SPs • Service Providers apply for R&S
– R&S SPs satisfy a modest set of requirements – An attribute bundle is associated with R&S – Operations staff vet and approve R&S applications
• R&S SPs are tagged in metadata – An entity attribute is inserted into SP metadata: <mdattr:EntityAttributes
xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<saml:Attribute
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Name="http://macedir.org/entity-category" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue>
http://id.incommon.org/category/research-and-scholarship
</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
www.incommon.org
Research & Scholarship IdPs • Identity Providers declare support for R&S
– IdPs release a minimal subset of the R&S attribute bundle – IdPs specify attribute release policy using entity attributes (not entityIDs)
• R&S IdPs are tagged in metadata – Like SPs, an entity attribute is inserted into IdP metadata: <mdattr:EntityAttributes
xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute">
<saml:Attribute
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Name="http://macedir.org/entity-category-support"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue>
http://id.incommon.org/category/research-and-scholarship
</saml:AttributeValue>
</saml:Attribute>
</mdattr:EntityAttributes>
www.incommon.org
REFEDS • Research & Education FEDerationS (REFEDS) • REFEDS promotes multilateral federation within the international
R&E sector • 40+ Federations and 7000+ published SAML entities worldwide
– Who said “SAML is dead!” – Metadata Explorer Tool: http://met.refeds.org/met/
• REFEDS web: https://refeds.org/ • REFEDS wiki: https://refeds.terena.org/index.php/ • Links to the metadata of a representative sample of international
Federations are given in the Training Exercises • eduGAIN • Code of Conduct
www.incommon.org
www.incommon.org
www.incommon.org
eduGAIN
• First and foremost, eduGAIN is a metadata aggregator
• 23 members + 7 joining + 1 candidate
http://www.edugain.org/technical/status.php
www.incommon.org
Code of Conduct
• If you think attribute release within higher ed is hard (in the face of FERPA), attribute release across the Atlantic Ocean is very hard
• The EU has a much stronger notion of privacy than the US
• For IdPs in the EU to release attributes to SPs in the US, an agreement equivalent to the Code of Conduct needs to be in place
• This is largely an unsolved problem
www.incommon.org
Metadata Exchange Models
• In general, the size of metadata aggregates is growing – InCommon metadata is ~9MB and it’s not even the largest
• Interfederation (if it catches on) will exacerbate the problem
• Other methods of metadata distribution are being investigated
• One alternative: Dynamic Metadata Exchange – The basic idea is to distribute per-entity metadata on demand (as
opposed to aggregates)
– A pilot study is planned
– The study will use the metadata query protocol
– Synergy with SAMLbits.org will be explored
www.incommon.org
Thank You!
• THANK YOU for participating in this training session!