1. 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

2. 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

3. Shibboleth Identity Provider Version 3
Scott Cantor
The Ohio State
University
Marvin Addison
Virginia Tech

4. A Bit of History Version 1 – 2003 – 2008 Version 2 – 2008 – 2015
SAML 1, inventing a lot of concepts on the fly
Version 2 – 2008 – 2015
SAML 2, harmonizing two protocols
Version 3 – ?
Focus on design, deployability, and sustainability over features

5. Why Upgrade? Compelling reasons for you Compelling reasons for us
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

6. 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
Velocity views generally live in idp.home/views
Message properties are in idp.home/messages; to internationalize, add a translation file such as authn-messages_fr.properties (in French for example)

7. 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.

8. 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

9. 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
(very incomplete so far)

10. 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

11. 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

12. 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

13. 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)
We have been scratching our own itch with CAS for nearly a decade.

14. IdP+CAS Background Virginia Tech has both CAS and Shibboleth
Both are essential 24x systems
One FTE for development and support of both
Rumors of IdPv3 multi-protocol support
Approach Shib dev team with proposal
CAS protocol support deemed feasible
VT contributes feature to ship with IdP 3.0
One system to rule them all

15. Protocol Design Goals Provide essential features of CAS protocol
Renew+gateway
Proxy (PGT/PT)
Attribute release
Logout/Single Logout (SLO)
Drop-in compatibility with popular CAS clients
Leverage IdPv3 design for new capabilities
New capabilities worth mentioning: attribute transforms, RP-based security policy, front-channel SLO, consent w/CAS.

16. Protocol Status CAS protocol v2 compliant CAS-flavored SAML 1.1
With attribute release “extension”
Without logout support
CAS-flavored SAML 1.1
Logout w/SLO slated for IdP 3.2.0
Beta status
Apache, Java, .NET, and PHP clients tested
VT production deployment planned
Evaluators needed
I’m happy to declare the beta over once we put it into production.

17. Protocol Requirements
Server-side IdP storage
MemoryStorageService
MemcachedStorageService
JPAStorageService
Configure metadata for relying parties
Service registry is familiar facility
CAS analogue of SAML metadata
(Optional) Proxy trust configuration
The ticket validation step of the CAS protocol is back-channel communication, which requires a server-side session store.
The CAS protocol endpoints are enabled in relying-party.xml as with SAML profiles.

18. Switching gears…

19. 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
We have been scratching our own itch with CAS for over a decade.
The human factors and policy around attribute release are at least 2 orders of magnitude greater than any technical considerations. While that is true for both CAS and Shib, it’s substantially harder for Shib.

20. Compelling Reasons to Upgrade
Consent engine solves policy headaches
SSO platform consolidation
Enhanced system architecture
Improved security policy machinery

21. Consent: #1 Driver for V3
Consent is a first-class new feature of IdPv3. We intend to take advantage of consent for SAML (InCommon) and CAS consumers.

22. Business Case for Consent
User consent solves FERPA morass
Accelerates service integration
Presently >30 days on average
Target <7 days on average
Friction-free integration with InC R&S services
Simplifies attribute release policy
Improves R&S compliance
CAS ecosystem benefits as well
ePPN and mail are FERPA-covered attributes in our view. FERPA morass applies any time a service target audience includes students and needs R&S attributes. That’s fairly common.
Students are not presently included in scope of R&S attribute bundle, which creates integration hassles.

23. 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.

24. Current SSO Two separate but integrated systems 2n everything
Development
Patches
Policy**
Complexity is the enemy
Policy is by far the most expensive in terms of time and energy.

25. Ideal SSO One system, two protocols Obvious Cost Benefits
Capabilities++
Consent
Attribute engine
2-factor authn
SLO
IdPv3 provides a more robust platform for multifactor authentication initiatives.
We expect we can implement front-channel SLO for CAS services on top of IdPv3 features.

26. IDPv3 Does HA Better Terracotta was never a tenable option
New StorageService API
More choices
Known, capable technologies
Fits any size deployment

27. Current IdP (2.x) Arch.

28. Planned IdP (3.x) Arch.
This is an architecture that has served us well for nearly 2 years with CAS.
Active-active deployments are the only reliable solution to (distributed) HA.

29. Security Policy Enhancements
Per-relying-party security policy is a real need: we’ve got two painful integrations that can’t do encryption.

30. 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

31. Evaluation
Please complete the evaluation of today’s webinar 31

32. Upcoming Events April – Internet2 Global Summit, Washington, DC October 4-7 – Technology Exchange, Cleveland, OH More information at 32