shibboleth 2 0 an overview for developers n.
Skip this Video
Loading SlideShow in 5 Seconds..
Shibboleth 2.0 : An Overview for Developers PowerPoint Presentation
Download Presentation
Shibboleth 2.0 : An Overview for Developers

Loading in 2 Seconds...

play fullscreen
1 / 17

Shibboleth 2.0 : An Overview for Developers - PowerPoint PPT Presentation

  • Uploaded on

Shibboleth 2.0 : An Overview for Developers. Scott Cantor The Ohio State University / Internet2. Resources. Web Site Documentation Wiki Self-Service Testing Facility

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Shibboleth 2.0 : An Overview for Developers' - zelig

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
shibboleth 2 0 an overview for developers

Shibboleth 2.0:An Overview for Developers

Scott Cantor

The Ohio State University / Internet2


Web Site

Documentation Wiki

Self-Service Testing Facility

SAML Specifications

  • Shibboleth Project
    • An umbrella of activities around federated authentication and access management managed by Internet2 and its international partners, still mostly an ad hoc group
  • Shibboleth Specifications
    • Historical extensions to SAML 1.1, now superseded by SAML 2.0
    • Strong commitment to standardization of any technical invention done on behalf of the project
  • Shibboleth System
    • Internet2-developed open-source implementation of various federation standards, specifications, and value-added components
    • Competitive with but also interoperating with many commercial and open source implementations
key concepts
Key Concepts
  • Federated Identity
  • Attribute-Based Single Sign-On
  • Management of Release of User Data
  • Standards Based
  • Variety of Policy and Management Models
  • Flexible Integration
  • Shibboleth 1.x spanned 4 major releases and several minor ones over a span of about 4 years.
  • Near-constant changes in terminology, configuration.
  • Following original standards track while contributing to the next generation of standards.
  • Essentially zero changes to actual applications across the entire release history.
general description of saml 2 0 sso
General Descriptionof SAML 2.0 SSO
  • Service provider sends XML <AuthnRequest> message to a trusted identity provider through browser.
  • Identity provider verifies identity of user and returns an XML <Response> message with an error or a signed SAML assertion to application through browser.
  • Assertion is optionally encrypted with a key controlled by service provider.
  • Security of system derived from keys exchanged among parties or indirectly via a PKI.
  • Lots of options and features, either further profiling or very comprehensive implementations.
saml 2 0 sso feature set
SAML 2.0 SSO Feature Set
  • Federated, multi-domain use
  • Carries attributes as well as identity
  • <AuthnRequest> features:
    • control over login methods (AuthnContext)
    • bypassing SSO (ForceAuthn)
    • requiring SSO (IsPassive)
    • control over identifier type (NameIDPolicy)
    • future control of forwardable assertions
  • Single Logout protocol, front and back-channel
  • Variety of deployment and trust models
shibboleth 2 0 value add
Shibboleth 2.0 Value Add
  • Uniform multi-protocol features
  • Advanced metadata exchange/processing
  • Internal / external authentication handlers
  • Zero-programming model for application integration
  • Advanced attribute features:
    • Integration with back-end stores
    • Extensible filtering at both ends
    • SP resolution architecture
  • Clustering
shibboleth application model
Shibboleth Application Model
  • SP software integrated with web server (Apache, IIS, Sun/iPlanet, FastCGI), not applications
  • Middleware consumes SAML assertions and filters/processes the claims while providing session mgmt (SAML token in, cookie out)
  • Applications generally written in terms of processed attributes, but can access raw tokens
shibboleth application model1
Shibboleth Application Model
  • Interface between applications and SP is designed to foster independence:
    • environment variables when possible
    • request headers otherwise
  • Applications with existing security or session models can use a trivial “stub” application to translate incoming attributes (store them in a database by session key, encrypt into cookie, map to local account or group, etc.)
typical deployment
Typical Deployment
  • Install SP software into web server.
    • Includes a keypair generator
  • Publish SAML metadata about service configuration.
    • SP can now generate mostly accurate metadata
    • Self-hosted or submitted to a federation operator for vetting and signing
  • Utilize access control functionality (e.g. Apache htaccess) based on attributes, if rules can be expressed externally to application.
  • Write application, consuming attributes when and where required as appropriate for the programming environment.
    • getenv(“HTTP_DISPLAYNAME”)
    • servletRequest.getAttribute(“displayName”)
    • Request(“HTTP_DISPLAYNAME”)
application sp integration
Application / SP Integration
  • As much as possible done through configuration at deployment time:
    • settings applied by host, path, query string, regular expressions
  • Advanced features like runtime control over login process available via redirection into SP handlers with parameters to supply or override settings.
  • Communication back to application also via redirects (e.g. notification of logout).
without programming
Without programming…
  • all protocol and XML processing
  • authorization based on attributes, SAML authentication context, time since login
  • session management with IP address enforcement
  • mapping of attributes to one or more headers, anything to REMOTE_USER
  • Require authentication and .edu faculty affiliation:
    • .htaccess

AuthType shibboleth

ShibRequireSession On

require affiliation ~ ^faculty@.+\.edu$

    • XML

<Path name=“myapp/secure” requireSession=“true”>


<RuleRegex require=“affiliation” ignoreCase=“true”>^faculty@.+\.edu$</RuleRegex>



  • Request a passive login(e.g. initial access to a portal):



  • Request a login via client certificate from Ohio State:


“/Shibboleth.sso/Login” +“?entityID=“ +“” +“&authnContextClassRef=“ +“urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient”);

current status
Current Status
  • 2.0 out, 2.1 imminent
    • bug fixes, additional clustering option using memcached
  • SP has more or less complete SAML 2.0 support
  • IdP TODO list includes single logout and NameID management protocols
roadmap items
Roadmap Items
  • Information Cards
  • Real-time user consent
  • User provisioning, “introduction” problem
  • Java SP
  • REST, WS-Trust, and SAML-based token requests
  • N-Tier solutions building on the previous item, perhaps OAuth, Keberos ticket delegation
  • Integration/glue for popular app frameworks
  • IdP package with embedded container