Transcript the slides

Shibboleth Identity Provider Version 3
IAM Online
March 11, 2015
Scott Cantor, Shibboleth Development Team
Marvin Addison, Shibboleth Development Team
Tom Barton, University of Chicago and InCommon TAC

The first, and foremost, achievement of the Internet2 Middleware
Initiative

Federation technology built on SAML is changing our world

SAML was declared dead before Shib was developed

Revived by Bob Morgan, powered by Scott Cantor

Interfederation is happening, providing the base on which an
access management decision can be effective anywhere in the
world

Shib IdP v3 is the best tool to manage your organization’s
integration with the global access management fabric
2
Shibboleth
Identity Provider
Version 3
Scott Cantor
The Ohio State
University
Marvin Addison
Virginia Tech
A Bit of History
• Version 1 – 2003 – 2008
•
SAML 1, inventing a lot of concepts on the fly
• Version 2 – 2008 – 2015
•
SAML 2, harmonizing two protocols
• Version 3 – 2015 - ?
•
Focus on design, deployability, and sustainability over
features
4
Why Upgrade?
• Compelling reasons for you
•
Easier UI and login customization, error handling,
simpler clustering, attribute release consent, easier
handling of vendor quirks, much improved update
process, CAS protocol support
• Compelling reasons for us
•
Up to date library stack, much easier to deliver future
enhancements, V2 maintenance is a drain on limited
resources
• A practical reason
•
V2 maintenance and user support is very finite; you
don't have to upgrade, but you can't stay here
5
User Interface
• Leverages "views" from Spring Web Flow
•
Views can be Velocity templates, JSP pages, potentially
others
•
Most views are Velocity by default so they can be
modified on the fly, including example
login/logout/error templates
• Spring message properties
•
Reusable macros across views (e.g., logo paths, titles,
organization names, etc.)
•
Can be internationalized to a browser's primary
language
6
Error Handling
• WebFlow is event-driven, so most errors are
"events", e.g., "MessageReplay"
• Events can be classified by you as Local or
non-Local, local meaning "don't issue a
response back to requester"
• Error view(s) under your control, an example
view is provided using message properties to
map events into different error content
• You can reuse example, roll your own, map
events to different views, etc.
7
Clustering
• Ding-dong, Terracotta's dead
• With one exception, all short/long-term
persistent state relies on a StorageService API
•
in-memory
•
cookie (*)
•
JPA / database
•
memcache
•
Web Storage (TBD)
• Defaults allow zero-effort clustering with
most critical features supported
8
Consent
• New first-order concept: interceptor flows
•
Security/policy checks run this way invisibly
•
Also have “post-authentication” hook for running flows
after user identified, several built-in examples
• uApprove-style attribute release consent and
terms of use flows (former is on by default on
new installs), has an enhanced mode of
approving each attribute individually
• Context-checking flow that can halt
processing if expected conditions aren’t met,
such as attributes or specific values available
9
Vendor Quirks
• Common use cases for integrating vendor
SAML implementations are easier and less
invasive
•
Security settings like digest algorithms can finally be
overridden per-SP or group of SPs
•
Assertion Encryption can be made “optional” so it turns
on whenever possible and off when not (based on
metadata)
•
Setting up custom NameID formats in a dedicated place
•
Attaching custom SAML encoder rules to attribute
definitions and limiting them to specific SPs
10
Safe Upgrades
• Simpler, safer, robust upgrade process:
•
Review release notes
•
Stop service
•
Unpack, install over top
•
Rebuild warfile to add back local changes
•
Start service
• Clearly delineated “system” and “user” config files
• Local warfile overlay to prevent losing webapp
changes or additions
• On Windows, Jetty can be installed and managed for
you in simple deployments, Unix TBD
11
CAS Protocol
• Major technical goal for redesign was to
facilitate non-SAML / non-XML protocol
integration
• CAS was a natural candidate to work on and
help prove out the design
12
Speaking with Developer “Hat”
● CAS application developer since ≈ 2005
● CAS server committer since ≈ 2010
● CAS server module lead (LDAP, X.509)
● Occasional CAS server release engineer
● Middleware contributed to a number of CAS
clients (Java, .NET, mod_auth_cas)
13
IdP+CAS Background
● Virginia Tech has both CAS and Shibboleth
o
Both are essential 24x7 99.98 systems
o
One FTE for development and support of both
● Rumors of IdPv3 multi-protocol support
● Approach Shib dev team with proposal
o
CAS protocol support deemed feasible
o
VT contributes feature to ship with IdP 3.0
● One system to rule them all
14
Protocol Design Goals
● Provide essential features of CAS protocol
o
Renew+gateway
o
Proxy (PGT/PT)
o
Attribute release
o
Logout/Single Logout (SLO)
● Drop-in compatibility with popular CAS clients
● Leverage IdPv3 design for new capabilities
15
Protocol Status
● CAS protocol v2 compliant
o
With attribute release “extension”
o
Without logout support
● CAS-flavored SAML 1.1
● Logout w/SLO slated for IdP 3.2.0
● Beta status
o
Apache, Java, .NET, and PHP clients tested
o
VT production deployment planned
o
Evaluators needed
16
Protocol Requirements
● Server-side IdP storage
o
MemoryStorageService
o
MemcachedStorageService
o
JPAStorageService
● Configure metadata for relying parties
o
Service registry is familiar facility
o
CAS analogue of SAML metadata
● (Optional) Proxy trust configuration
17
Switching gears…
18
Speaking with Deployer “Hat”
● Virginia Tech adopted CAS circa 2003
● Virginia Tech adopted Shib circa 2006
● CAS gets the majority of resources
● Our IdPv2 infrastructure needs some love
● We have considered consolidating on a single
SSO platform for years
● Attribute release policy is a pain
19
Compelling Reasons to Upgrade
● Consent engine solves policy headaches
● SSO platform consolidation
● Enhanced system architecture
● Improved security policy machinery
20
Consent: #1 Driver for
V3
21
Business Case for Consent
● User consent solves FERPA morass
● Accelerates service integration
o
Presently >30 days on average
o
Target <7 days on average
o
Friction-free integration with InC R&S services
● Simplifies attribute release policy
● Improves R&S compliance
● CAS ecosystem benefits as well
22
Consolidate and Save
● Time
● Money
● Headaches
If you are a CAS+Shib school like Virginia Tech,
there’s an obvious case to be made for a single
SSO service at your school.
23
Current
SSO
● Two separate
but integrated
systems
● 2n everything
○
○
○
Development
Patches
Policy**
● Complexity is
the enemy
24
Ideal
SSO
● One system,
two protocols
● Obvious Cost
Benefits
● Capabilities++
●
●
●
●
Consent
Attribute engine
2-factor authn
SLO
25
IDPv3 Does HA Better
● Terracotta was never a tenable option
● New StorageService API
o
More choices
o
Known, capable technologies
o
Fits any size deployment
26
Current
IdP (2.x)
Arch.
Planned
IdP (3.x)
Arch.
Security Policy Enhancements
29
Make Plans to Upgrade!


Manage through ever increasing security and trust needs
 SHA-1 → SHA-2

Categories/Tags


Per-entity or entity group
2FA

Consent
InCommon encourages you to!
 Updating Shib training to be v3 focused

Updating wiki doc

Baseline practices, participant and federation, to be revised in light of
those ever-increasing security and trust needs
30
Evaluation
Please complete the evaluation of today’s webinar
https://www.surveymonkey.com/s/IAM_Online_March_2015
31
Upcoming Events
April 26-30 – Internet2 Global Summit, Washington, DC
October 4-7 – Technology Exchange, Cleveland, OH
More information at www.internet2.edu
32