Upgrade Reasons and UI Customization
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
2
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
3
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
4
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.
5
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
6
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
7
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
8
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
9
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
10
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)
11
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
12
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
13
Protocol Status
●
CAS protocol v2 compliant
o
With attribute release “extension”
o
With
out
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
14
Protocol Requirements
●
Server-side IdP stor
age
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
15
Switching gears…
16
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
17
Compelling Reasons to Upgrade
●
Consent engine solves policy headaches
●
SSO platform consolidation
●
Enhanced system architecture
●
Improved security policy machinery
18
Consent: #1 Driver for
V
3
19
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
20
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.
21
Current
SSO
22
●
Two separate
but integrated
systems
●
2n everything
○
Development
○
Patches
○
Policy**
●
Complexity is
the enemy
Ideal
SSO
23
●
One system,
two protocols
●
Obvious Cost
Benefits
●
Capabilities++
●
Consent
●
Attribute engine
●
2-factor authn
●
SLO
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
24
Current
IdP (2.x)
Arch
.
Planned
IdP (3.x)
Arch
.
Security Policy Enhancements
27
Shibboleth Identity Provider versions evolution, reasons to upgrade to version 3 for enhanced UI and functionality, leveraging Spring Web Flow for user interface customization, event-driven error handling, and clustering features.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
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 2
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 3
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 4
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. 5
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 6
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 7
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 8
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 9
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 10
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) 11
IdP+CAS Background Virginia Tech has both CAS and Shibboleth Both are essential 24x7 99.98 systems o One FTE for development and support of both o Rumors of IdPv3 multi-protocol support Approach Shib dev team with proposal CAS protocol support deemed feasible o VT contributes feature to ship with IdP 3.0 o One system to rule them all 12
Protocol Design Goals Provide essential features of CAS protocol Renew+gateway o Proxy (PGT/PT) o Attribute release o Logout/Single Logout (SLO) o Drop-in compatibility with popular CAS clients Leverage IdPv3 design for new capabilities 13
Protocol Status CAS protocol v2 compliant With attribute release extension o Without logout support o CAS-flavored SAML 1.1 Logout w/SLO slated for IdP 3.2.0 Beta status Apache, Java, .NET, and PHP clients tested o VT production deployment planned o Evaluators needed o 14
Protocol Requirements Server-side IdP storage MemoryStorageService o MemcachedStorageService o JPAStorageService o Configure metadata for relying parties Service registry is familiar facility o CAS analogue of SAML metadata o (Optional) Proxy trust configuration 15
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 17
Compelling Reasons to Upgrade Consent engine solves policy headaches SSO platform consolidation Enhanced system architecture Improved security policy machinery 18
Business Case for Consent User consent solves FERPA morass Accelerates service integration Presently >30 days on average o Target <7 days on average o Friction-free integration with InC R&S services o Simplifies attribute release policy Improves R&S compliance CAS ecosystem benefits as well 20
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. 21
Current SSO Two separate but integrated systems 2n everything Development Patches Policy** Complexity is the enemy 22
Ideal SSO One system, two protocols Obvious Cost Benefits Capabilities++ Consent Attribute engine 2-factor authn SLO 23
IDPv3 Does HA Better Terracotta was never a tenable option New StorageService API More choices o Known, capable technologies o Fits any size deployment o 24
Current IdP (2.x) Arch.
Planned IdP (3.x) Arch.
