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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
● 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
● 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 o
CAS protocol support deemed feasible
VT contributes feature to ship with IdP 3.0
● One system to rule them all
14
● Provide essential features of CAS protocol o
Renew+gateway o o o
Proxy (PGT/PT)
Attribute release
Logout/Single Logout (SLO)
● Drop-in compatibility with popular CAS clients
● Leverage IdPv3 design for new capabilities
15
● 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 o
VT production deployment planned
Evaluators needed
16
● Server-side IdP storage o
MemoryStorageService o o
MemcachedStorageService
JPAStorageService
● Configure metadata for relying parties o
Service registry is familiar facility o
CAS analogue of SAML metadata
● (Optional) Proxy trust configuration
17
18
● 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
● Consent engine solves policy headaches
●
● Enhanced system architecture
● Improved security policy machinery
20
21
● User consent solves FERPA morass
● Accelerates service integration o o
Presently >30 days on average
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
● 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
● Two separate but integrated systems
● 2n everything
○ Development
○ Patches
○ Policy**
● Complexity is the enemy
24
● One system, two protocols
● Obvious Cost
Benefits
● Capabilities++
● Consent
● Attribute engine
● 2-factor authn
● SLO
25
● Terracotta was never a tenable option
● New StorageService API o o
More choices
Known, capable technologies o
Fits any size deployment
26
29
Manage through ever increasing security and trust needs
SHA1 → 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
Please complete the evaluation of today’s webinar https://www.surveymonkey.com/s/IAM_Online_March_2015
31
April 26-30 – Internet2 Global Summit, Washington, DC
October 4-7 – Technology Exchange, Cleveland, OH
More information at www.internet2.edu
32