Shibboleth Working Group, Fall 2010

Scott Cantor, OSUChad LaJoie, Itumi, LLC

Roadmap

Roadmap• Committed Work

• Necessary/expected ongoing functions

• Funded/staffed projects

• Planned Work• Accepted for prioritization but uncommitted

• Under Discussion

• Rejected/Parked Work• Lacking in some regard

• Subject to re-evaluation when circumstances change

3

Committed• Project Overhead

• User Support

• Supported Release Maintenance

• SP 2.4

• “Embedded” Discovery Service

• Metadata Aggregator

4

Planned• Expanded introductory documentation

• V3 IdP / OpenSAML-J

• V2 Discovery Service

• V3 TestShib

• Back-channel Single Logout for the IdP

• Second Factor Authentication via SMS

• SP Delegation Enhancement (deferred from 2.4)

5

Service Provider

Service Provider V2.4• Release Candidate now available

• Minor feature update / bug fix rollup

• Backward compatible per usual

• Simplified configuration/defaults

• Metadata- and discovery-related enhancements

• Security changes

• Logging/monitoring changes

7

Configuration• https://spaces.internet2.edu/x/fIk9

• “Radical” defaulting of rarely-changed settings

• Reduction of order strictness

• Factored security policy rules into separate file

• Consistent message regarding Apache configuration via Apache commands

• Shorthand syntax for configuring “most” SSO/Logout needs

• 260+ lines to 120 lines8

Metadata• Background reloading of configuration /

metadata resources

• Caching (incl. across restarts) and compression

• Delays backup overwrite until filtering completes

• Rational cacheDuration handling

• Support for extension drafts:• http://wiki.oasis-open.org/security/SAML2MetadataUI

• http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport

9

Discovery• Supporting role; provide a “usable” view of

IdP information extracted from metadata to discovery component

• Supplies JSON data from each metadata source• Name/description/logo derived from

<mdui:UIInfo> metadata extension

• New handler aggregates and serves JSON to client

• Discovery scripts may or may not be in 2.4 release, probably not

10

Security• Update/bug fix release of xml-security library

• Whitelisting/blacklisting of crypto algorithms at “application” level

• Conditional support of ECDSA signatures

• Dynamic selection of algorithms based on metadata extension:• <alg:DigestMethod>

• <alg:SigningMethod>

• <md:EncryptionMethod>

11

Logging / Monitoring• New default logging configuration:

• Mirrors WARN and higher to a warning log to highlight problems

• Dedicated debugging log for signature issues

• Status handler includes local system time and OS-derived platform data

12

Discovery Service

DS: Embedded• Make discovery easier for SPs to deploy

• Consumes data from SP 2.4

• Added to a page by:• adding a <div>

• adding two <script>

• Beta release in November

https://spaces.internet2.edu/display/SHIB2/DSRoadmap

DS: Centralized• Use embedded DS as primary UI

• Better APIs for filtering and sorting

• Configuration more aligned with IdP

• Distributed with configured container

Identity Provider

Identity Provider• Profile handlers to accommodate more in-flow

extensions• e.g. terms of use, attribute consent, holder of key

support

• Rework authentication APIs• better support for non-browser clients

• support for SPNEGO, OTP

https://spaces.internet2.edu/display/SHIB2/IdPRoadmap

Identity Provider• Reduced configuration files

• Support for <md:EncryptionMethod>

• HA-Shib like clustering:• reduced configuration

• no process to manage & monitor

• provides a clustered data store

https://spaces.internet2.edu/display/SHIB2/IdPSimplifyConfig

SPNEGO

What is SPNEGO• Log in to Kerberos/Windows domain

• No need to log in to websites

Why is it hard?

Why is it hard?• 403 error page if SPNEGO not configured or

user not logged in to domain

• No way to query the browser to determine if SPNEGO is configured

• Nothing a user can do once they get a 403

How do we fix it?• Provide users a choice to log in with SPNEGO

• Provide a link to a separate app that:• checks if a browser is configured

• provides browser specific config guides

• sets a permanent cookie if user/browser can’t support SPNEGO

How do we fix it?

One Time Password

Why?• Certain use cases want multi-factor authn

• User certs and time sync tokens are hard and expensive to roll out

How?1. User logs in2. SMS with one-time code sent3. User enters it in the IdP

• Google recently deployed a similar scheme

Technical Details• Requires two log in screens as user has to be

identified (by first factor) in order to know to whom to send the SMS

• Sites deploying will need to provide a way for users to opt-in in to such a method

• Might need to send a few tokens to users ahead of time in case they don’t have cell access