Presentation on theme: "Shibboleth Identity Provider Version 3 IAM Online March 11, 2015"— Presentation transcript:
1 Shibboleth Identity Provider Version 3 IAM Online March 11, 2015 Scott Cantor, Shibboleth Development TeamMarvin Addison, Shibboleth Development TeamTom 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 worldSAML was declared dead before Shib was developedRevived by Bob Morgan, powered by Scott CantorInterfederation is happening, providing the base on which an access management decision can be effective anywhere in the worldShib 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 CantorThe Ohio StateUniversityMarvin AddisonVirginia Tech
4 A Bit of History Version 1 – 2003 – 2008 Version 2 – 2008 – 2015 SAML 1, inventing a lot of concepts on the flyVersion 2 – 2008 – 2015SAML 2, harmonizing two protocolsVersion 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 supportCompelling reasons for usUp to date library stack, much easier to deliver future enhancements, V2 maintenance is a drain on limited resourcesA practical reasonV2 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 othersMost views are Velocity by default so they can be modified on the fly, including example login/logout/error templatesSpring message propertiesReusable macros across views (e.g., logo paths, titles, organization names, etc.)Can be internationalized to a browser's primary languageVelocity views generally live in idp.home/viewsMessage properties are in idp.home/messages; to internationalize, add a translation file such as authn-messages_fr.properties (in French for example)
7 Error HandlingWebFlow 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 contentYou can reuse example, roll your own, map events to different views, etc.https://wiki.shibboleth.net/confluence/display/IDP30/ErrorHandlingConfiguration
8 Clustering Ding-dong, Terracotta's dead With one exception, all short/long-term persistent state relies on a StorageService APIin-memorycookie (*)JPA / databasememcacheWeb Storage (TBD)Defaults allow zero-effort clustering with most critical features supportedhttps://wiki.shibboleth.net/confluence/display/IDP30/Clustering
10 Vendor QuirksCommon use cases for integrating vendor SAML implementations are easier and less invasiveSecurity settings like digest algorithms can finally be overridden per-SP or group of SPsAssertion 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 placeAttaching custom SAML encoder rules to attribute definitions and limiting them to specific SPshttps://wiki.shibboleth.net/confluence/display/IDP30/SecurityConfigurationhttps://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfigurationhttps://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration
11 Safe Upgrades Simpler, safer, robust upgrade process: Review release notesStop serviceUnpack, install over topRebuild warfile to add back local changesStart serviceClearly delineated “system” and “user” config filesLocal warfile overlay to prevent losing webapp changes or additionsOn Windows, Jetty can be installed and managed for you in simple deployments, Unix TBDhttps://wiki.shibboleth.net/confluence/display/IDP30/Upgrading
12 CAS ProtocolMajor technical goal for redesign was to facilitate non-SAML / non-XML protocol integrationCAS was a natural candidate to work on and help prove out the design
13 Speaking with Developer “Hat” CAS application developer since ≈ 2005CAS server committer since ≈ 2010CAS server module lead (LDAP, X.509)Occasional CAS server release engineerMiddleware 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 systemsOne FTE for development and support of bothRumors of IdPv3 multi-protocol supportApproach Shib dev team with proposalCAS protocol support deemed feasibleVT contributes feature to ship with IdP 3.0One system to rule them all
15 Protocol Design Goals Provide essential features of CAS protocol Renew+gatewayProxy (PGT/PT)Attribute releaseLogout/Single Logout (SLO)Drop-in compatibility with popular CAS clientsLeverage IdPv3 design for new capabilitiesNew 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 supportCAS-flavored SAML 1.1Logout w/SLO slated for IdP 3.2.0Beta statusApache, Java, .NET, and PHP clients testedVT production deployment plannedEvaluators neededI’m happy to declare the beta over once we put it into production.
17 Protocol Requirements Server-side IdP storageMemoryStorageServiceMemcachedStorageServiceJPAStorageServiceConfigure metadata for relying partiesService registry is familiar facilityCAS analogue of SAML metadata(Optional) Proxy trust configurationThe 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.
19 Speaking with Deployer “Hat” Virginia Tech adopted CAS circa 2003Virginia Tech adopted Shib circa 2006CAS gets the majority of resourcesOur IdPv2 infrastructure needs some loveWe have considered consolidating on a single SSO platform for yearsAttribute release policy is a painWe 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 headachesSSO platform consolidationEnhanced system architectureImproved security policy machinery
21 Consent: #1 Driver for V3Consent 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 morassAccelerates service integrationPresently >30 days on averageTarget <7 days on averageFriction-free integration with InC R&S servicesSimplifies attribute release policyImproves R&S complianceCAS ecosystem benefits as wellePPN 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 DevelopmentPatchesPolicy**Complexity is the enemyPolicy is by far the most expensive in terms of time and energy.
25 Ideal SSO One system, two protocols Obvious Cost Benefits Capabilities++ConsentAttribute engine2-factor authnSLOIdPv3 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 APIMore choicesKnown, capable technologiesFits any size deployment
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 needsSHA-1 → SHA-2Categories/TagsPer-entity or entity group2FAConsentInCommon encourages you to!Updating Shib training to be v3 focusedUpdating wiki docBaseline practices, participant and federation, to be revised in light of those ever-increasing security and trust needs
31 EvaluationPlease complete the evaluation of today’s webinar https://www.surveymonkey.com/s/IAM_Online_March_201531
32 Upcoming Events April – Internet2 Global Summit, Washington, DC October 4-7 – Technology Exchange, Cleveland, OH More information at32