Shibboleth 2.0 SP slides - Installfest

Shibboleth 2.0 InstallFest Service Provider Material May 2008 Ann Arbor, MI

SP Overview and Installation

Bearings and Terminology

Installation and Directory Structure

Generating Key and Certificate

Picking an entityID

Initial Configuration

Testing

System Environment

CentOS (Red Hat) 5 VM, ssh, "password"

Apache 2.2, running on standard ports

Bogus SSL certificates

AuthConfig added to /cgi-bin for .htaccess

Hostnames:

sp N .example.com

altsp N .example.com (later)

Terminology

Service Provider

SAML-enabling middleware for web applications

shibd

SP service/daemon for maintaining state

Session

Security context and cached data for a logged-in user

SessionInitiator

Part of SP that generates SSO requests

MetadataProvider

Provides secure information about IdPs at runtime

CredentialResolver

Interface from SP to its keys and certificates

Installation

RPM-based:

$ rpm –ivh /opt/installfest/RPMS/*.rpm

Done by RPM after installation:

cp /etc/shibboleth/apache22.conf ig/etc/httpd/conf.d/shib.conf

cp /etc/shibboleth/shibd-redhat /etc/init.d/shibd

Sanity Checks

Start processes:

$ /etc/init.d/shibd start

$ /etc/init.d/httpd start

Check status locally from shell:

$ curl -k https://localhost/Shibboleth.sso/Status

Access session handler from browser:

https://sp N .example.com/Shibboleth.sso/Session

Intentionally trigger an error from browser:

https://sp N .example.com/Shibboleth.sso/Foo

Binaries

/usr/sbin/shibd

/usr/bin/resolvertest

/usr/bin/mdquery

/usr/lib/shibboleth/*.so

Apache/etc. modules, SP extensions

Supporting Files

/etc/shibboleth

master and supporting configuration files

locally maintained metadata files

HTML templates

logging configuration files

credentials

/var/run/shibboleth

UNIX socket

remote metadata backups

/var/log/shibboleth

shibd and transaction logs

/var/log/httpd

native log (after permission change)

Key/Certificate Generation

/etc/shibboleth/keygen.sh

Runs automatically during installation on most platforms.

For this event, copy over a pre-generated set for your assigned SP number:

$ cp /opt/installfest/sp N /sp.key /etc/shibboleth/sp-key.pem

$ cp /opt/installfest/sp N /sp.crt /etc/shibboleth/sp-cert.pem

Picking an entityID

How NOT to do it (but we’re doing it anyway):

https://sp N .example.com/shibboleth

Why not?

Names should be unique, locally scoped, logical, representative, unchanging.

Where are they used?

On the wire, local configuration, metadata

IdP log files, configuration, filtering policies

Bootstrapping the SP

Goals:

working SP against a single IdP

enable debugging of session attributes

avoid clock complaints

Give Apache the hostname.

$ vi /etc/httpd/conf/httpd.conf

Line 265:

ServerName sp N .example.com

Bootstrapping the SP (cont.)

Relax some requirements and set your entityID and the IdP’s entityID.

$ vi /etc/shibboleth/shibboleth2.xml

Line 6 (Do NOT do this in production) :

logger="syslog.logger" clockSkew="180000" >

Line 77:

<ApplicationDefaults id="default" policyId="default" entityID="https://sp N .example.com/shibboleth" >

Line 105:

<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID="https://testidp.example.com/idp/shibboleth" >

Line 184:

<Handler type="Session" Location="/Session" showAttributeValues="true" />

Bootstrapping the SP (cont.)

Provide metadata remotely from test IdP:

Line 208:

<MetadataProvider type="Chaining">

<MetadataProvider type="XML" url="https://testidp.example.com/testidp-metadata.xml" backingFilePath="testidp-metadata.xml" reloadInterval="3600"/>

Supply metadata to parties of interest. (done for you)

$ curl -k https://sp N .example.com/Shibboleth.sso/Metadata

Testing the SP

Try it with a browser:

https://sp N .example.com/cgi-bin/test

Dump your session:

Logging Out

To logout locally from the SP and kill your session:

https://sp N .example.com/Shibboleth.sso/Logout

Or just close the browser and start over.

Trying your own IdP

Adjust SessionInitiator and add metadata for your IdP to your SP:

Line 105:

<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID="https://idp N .example.com/idp/shibboleth" >

Line 208:

<MetadataProvider type="XML" path="/opt/installfest/idp N /idp N -metadata.xml"/>

Add metadata for your SP to your IdP:

$ vi /opt/shibboleth-idp/conf/relying-party.xml

<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata">

<MetadataProvider id="SP N " xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"

metadataFile="/opt/installfest/sp N /sp N -metadata.xml"/>

Testing

Restart Tomcat (and the IdP)

$ /etc/init.d/tomcat stop

$ ps –ef | grep java

$ /etc/init.d/tomcat restart

Try it with a browser:

Dump your session:

Use a Discovery Service

Use a discovery service by changing the default SessionInitiator:

Line 105:

<SessionInitiator type="Chaining" Location="/Login" isDefault="false" id="Intranet" relayState="cookie"

Line 119:

<SessionInitiator type="Chaining" Location="/DS" id="DS" relayState="cookie" isDefault="true" acsByIndex="false" >

<SessionInitiator type="SAML2" defaultACSIndex="1" …/>

<SessionInitiator type="Shib1" defaultACSIndex="5"/>

<SessionInitiator type="SAMLDS" URL="https://ds.example.com/DS/WAYF" />

</SessionInitiator>

Lazy Sessions

The mode of operation so far prevents an application from running without a login.

Two other very common cases:

public and private access to the same resources

separation of application and SP session

Semantics are: if valid session exists, then process it as usual (attributes in headers, REMOTE_USER, etc.), but if a session does NOT exist or is invalid, ignore it and pass on control.

Using Lazy Sessions

In place of an API to "doLogin", the SP uses redirects:

https://testsp1.example.com/Shibboleth.sso/Login

When you want a login to happen, redirect the browser to a SessionInitiator (/Login by convention) with any parameters you want to supply.

Session Creation Parameters

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

Key Parameters

target (defaults to homeURL or "/")

entityID (IdP to use, if known)

Most parameters can come from three places, in order of precedence:

query string parameter to handler

a content setting (.htaccess or RequestMap)

<SessionInitiator> element

Lazy Session Example

Access unprotected script:

https://sp N .example.com/cgi-bin/content

View source to see the Login links:

/Shibboleth.sso/Login?target=/cgi-bin/content

/Shibboleth.sso/DS?target=/cgi-bin/content

Copy it and add any other parameters to see the result: e.g. try supplying the IdP:

/Shibboleth.sso/Login? target=/cgi-bin/content& entityID=https://idp N .example.com/idp/shibboleth

END

SP Basic Configuraton

Summary of Files

Structure of Master Configuration

Changing Logging Levels

Metadata

.htaccess

RequestMap

Handlers

Configuration Files /etc/shibboleth

shibboleth2.xml – master

apache*.config – Apache module loading

attribute-map.xml – attribute handling

attribute-policy.xml – attribute filtering

*.logger – logging levels

*Error.html – error templates

localLogout.html – SP-only logout template

globalLogout.html – single logout template

shibboleth2.xml Structure

<OutOfProcess> / <InProcess>

<UnixListener> / <TCPListener>

<StorageService>

<SessionCache>

<ReplayCache>

<ArtifactMap>

<RequestMapper>

<ApplicationDefaults>

<SecurityPolicies>

shibboleth2.xml Structure

<ApplicationDefaults>

<Sessions>

<Errors>

<RelyingParty> (*)

<MetadataProvider>

<TrustEngine>

<AttributeExtractor>

<AttributeResolver>

<AttributeFilter>

<CredentialResolver>

<ApplicationOverride> (*)

Logging

Logging controlled independently between Apache and shibd (or globally to a syslog)

Transaction log handled out of shibd as a separate stream

*.logger files contain predefined settings for output locations and a default logging level (INFO) along with useful categories to raise to DEBUG

Logging: Tracing Messages

Raise categories:

$ vi shibd.logger

Line 14:

# tracing of SAML messages and security policies

log4j.category.OpenSAML.MessageDecoder=DEBUG

log4j.category.OpenSAML.MessageEncoder=DEBUG

log4j.category.OpenSAML.SecurityPolicyRule=DEBUG

To implement *.logger changes:

$ touch shibboleth2.xml

$ tail -f /var/log/shibboleth/shibd.log

Test the SP again:

SP Metadata Features

Four primary methods built-in:

Local file (you manage it)

Remote file (periodic refresh, backed up for you)

Dynamic resolution of entityID

"Null" source that disables security

Security comes from metadata filtering, either by you or the SP:

Signature verification

White and blacklists

Signature Verification

The test IdP's metadata is signed. Up until now, you loaded it without checking.

First, "break" it:

Line 208:

<MetadataProvider type="XML" url="https://testidp.example.com/testidp-metadata.xml" backingFilePath="testidp-metadata.xml" reloadInterval="3600">

<SignatureMetadataFilter certificate="sp-cert.pem"/>

</MetadataProvider>

Signature Verification

Now preinstall the right signing key:

$ cd /etc/shibboleth

$ wget https://testidp.example.com/idp.crt

Then fix it:

Line 208:

<MetadataProvider type="XML" url="https://testidp.example.com/testidp-metadata.xml" backingFilePath="testidp-metadata.xml" reloadInterval="3600">

<SignatureMetadataFilter certificate=" idp.crt "/>

</MetadataProvider>

Content Settings

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

Per-host, -directory, -file, -query

Apache

.htaccess

Apache / IIS / other

RequestMap

Requires meticulous hostname "agreement" (we'll demo this later)

Testing with:

https://sp N .example.com/cgi-bin/content

.htaccess Examples

Requiring authentication:

$ vi /var/www/cgi-bin/.htaccess

AuthType shibboleth

require shibboleth

ShibRequestSetting requireSession 1

.htaccess Examples

Auto-redirecting to SSL:

AuthType shibboleth

require shibboleth

ShibRequestSetting redirectToSSL 443

.htaccess Examples

Bypassing SSO:

AuthType shibboleth

require shibboleth

ShibRequestSetting forceAuthn 1

RequestMap Examples

Make sure .htaccess is in its original state.

Requiring authentication:

Line 62:

<Host name=" sp N .example.com ">

<Path name=" cgi-bin " authType="shibboleth"

requireSession="true"/>

</Host>

RequestMap Fragility

By default, Apache "trusts" the client about what the requested hostname is and reports that value internally.

To illustrate, now that the "content" script is protected, try this URL:

https://altsp N .example.com/cgi-bin/content

How to fix?

vi /etc/httpd/conf/httpd.conf

UseCanonicalName On

RequestMap Examples

Auto-redirecting to SSL:

Line 62:

<Host name="sp N .example.com">

<Path name="cgi-bin" authType="shibboleth"

requireSession="true" redirectToSSL="443" />

</Host>

RequestMap Examples

Bypassing SSO:

Line 62:

<Path name="cgi-bin" authType="shibboleth"

requireSession="true" forceAuthn="true" />

</Host>

Other Content Settings

Requesting types of authentication

Error handling pages

Redirection-based error handling

isPassive

Supplying a specific IdP to use

SP Handlers

"Virtual" applications inside the SP with access to its APIs:

SessionInitiator (requests)

AssertionConsumerService (incoming SSO)

LogoutInitiator (SP signout)

SingleLogoutService (incoming SLO)

ManageNameIDService (adv. SAML)

ArtifactResolutionService (adv. SAML)

Generic (diagnostics, other useful features)

SP Handlers

The URL of a handler is the handlerURL + the Location of the handler.

e.g. for a virtual host testsp.example.com with handlerURL of "/Shibboleth.sso", a handler with a Location of "/Login" will be https://testsp.example.com/Shibboleth.sso/Login

Handlers aren’t always SSL-only, but usually should be (handlerSSL="true").

Most of your metadata consists of your entityID, your keys, and your handlers.

Handlers are never "protected" by the SP.

Some Handler Options

SessionInitiator and LogoutInitiators are the most "tweakable". Some minor examples:

Remove relayState to pass URLs by value.

Line 105:

<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID="https://testidp.example.com/idp/shibboleth">

Switch to Artifact binding for response:

Line 105:

<SessionInitiator type="SAML2" defaultACSIndex="2" template="bindingTemplate.html"/>

Switch from SAML 2 Redirect to POST:

Line 105:

<SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"

outgoingBindings="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" />

END

SP Attribute Handling

Terminology

Scoped Attributes

Adding New Attribute Mappings

REMOTE_USER and Identifiers

Filtering Overview

Source-Based Filtering

Access Control

SP Attribute Terminology

Push

delivering attributes with SSO assertion

Pull

querying for attributes after SSO

Extraction

decoding SAML information into neutral data structures mapped to environment or header variables

Filtering

blocking invalid, unexpected, or unauthorized values based on application or community criteria

Resolution

resolving a SSO assertion into a set of additional attributes (e.g. queries)

Scoped Attributes

Common term across I2 middleware for attributes that consist of a relation between a value and a "scope", usually an organizational domain or subdomain.

Makes simpler values globally usable or unique.

Lots of special treatment in Shibboleth to make them more useful and "safe".

Attribute Mappings

SAML attributes from any source are "extracted" using the configuration rules in attribute-map.xml

Each element is a rule for decoding a SAML attribute and assigning it a local "id" which becomes its mapped variable name.

Attributes can have > 1 "id" and multiple attributes can be mapped to the same "id".

Decoders are attribute-independent but syntax-dependent.

Dissecting an attribute rule

<Attribute id="affiliation" aliases="affil"

name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation">

<AttributeDecoder xsi:type="ScopedAttributeDecoder"

caseSensitive="false"/>

</Attribute>

id

the primary "id" to map into

aliases

optional alternate names to map into

name

SAML attribute name or NameID format to map from

AttributeDecoder xsi:type

decoder plugin to use (defaults to simple/string)

caseSensitive

how to compare values at runtime (defaults to true)

Adding mappings

Add first and last name for both SAML 1 and SAML 2:

$ vi /etc/shibboleth/attribute-map.xml

<Attribute name="urn:mace:dir:attribute-def:sn" id="sn"/>

<Attribute name="urn:mace:dir:attribute-def:givenName" id="givenName"/>

<Attribute name="urn:oid:2.5.4.4" id="sn"/>

<Attribute name="urn:oid:2.5.4.42" id="givenName"/>

Takes effect immediately but NOT for any existing sessions.

REMOTE_USER

Special single-valued variable that all web applications should support for container-managed authentication of a unique user.

Any attributes, once extracted/mapped, can be copied to REMOTE_USER.

Multiple attributes can be examined in order of preference, but only the first value will be used.

Changing REMOTE_USER

Put the "sn" attribute into REMOTE_USER:

Line 80:

REMOTE_USER=" sn eppn"

Note without the mappings added earlier, no change will occur.

Attribute Filtering

Answers the "who can say what" question on behalf of an application.

Usual examples:

constraining the possible values of an attribute (e.g. eduPersonAffiliation)

limiting the scopes/domains an IdP can speak for (e.g. OSU cannot assert faculty@umich.edu)

limiting custom attributes to particular sources

Default Policy

Shared rule for legal affiliation values

Shared rule for scoped attributes

Generic policy applying those rules and letting all other attributes through.

Check /var/log/shibboleth/shibd.log for signs of filtering…

Combining policies currently a bit buggy in IdP and SP, fix forthcoming.

Add a Source-Based Rule

Add a rule to limit acceptance of "sn" to a single IdP:

$ vi /etc/shibboleth/attribute-policy.xml

Line 55:

<afp:AttributeRule attributeID="sn">

<afp:PermitValueRule xsi:type="AttributeIssuerString" value="https://idp N .example.com/idp/shibboleth"/>

</afp:AttributeRule>

Access Control

Not formally part of the SP, but cleanly integrated with it via an AccessControl API built into the request processing flow.

Two implementations are provided:

.htaccess "require" rule processing

XML-based policy syntax attached to content via RequestMap

.htaccess Access Control

Special rules:

shibboleth (no authz)

valid-user (require a session, but NOT identity)

user (REMOTE_USER as usual)

group (group files as usual)

authnContextClassRef, authnContextDeclRef

"OR" implied unless ShibRequireAll used

Regular expressions supported using special syntax:

require rule ~ exp

.htaccess Example

Require an entitlement or specific users:

AuthType shibboleth

require entitlement http://channel8.msdn.com/user

require user ~ ^staff(1|2)@example.com$

XML Access Control

Portable across servers, mainly an example of what's possible; competing with XACML is not a goal.

For convenience, embeddable inside RequestMap syntax, but can be externalized.

Same special rules as .htaccess, adds boolean operators (<AND>,<OR>,<NOT>).

XML Example

Require an entitlement or specific users:

Line 62:

<Path name="cgi-bin" authType="shibboleth" requireSession="true">

<AccessControl>

<OR>

<Rule require="entitlement"> http://channel8.msdn.com/user</Rule>

<RuleRegex require="user">^staff(1|2)@example.com$</RuleRegex>

</OR>

</AccessControl>

</Path>

</Host>

END

Session Initiators / Discovery

Concepts

Chains and protocol precedence

Lazy sessions

Discovery services

Internal discovery mechanisms

Session Initiators / Discovery Concepts

Session Initiator

handler that creates a SSO request for an IdP or uses a discovery mechanism to identity the IdP (or both)

Discovery (in Shibboleth)

identifying the IdP of a particular user

can be internal or external, automatic or invasive

WAYF Service

old name in Shibboleth for a particular way to do discovery

Handler Chain

sequence of handlers that share configuration and run consecutively until "something useful happens" or an error occurs

Simplest Case

Single IdP, single protocol, no discovery:

<SessionInitiator

type="SAML2" id="simple" isDefault="true"

Location="/Login"

entityID="https://testidp.example.com/idp/shibboleth"

relayState="cookie"

defaultACSIndex="1"

template="bindingTemplate.html"

/>

Resembles the typical approach used in 1.3 SP but omits hardcoding the IdP's location.

Intranet Case

Single IdP, multiple protocols, no discovery:

<SessionInitiator type="Chaining" Location="/Login"

id="Intranet" isDefault="true" relayState="cookie"

entityID=" https://testidp.example.com/idp/shibboleth">

</SessionInitiator>

Protocol precedence controlled by order of chain.

Common properties defined at the top and inherited by chain links.

Favoring Legacy Protocol

Switch order of chain:

Line 105:

<SessionInitiator type="Chaining" Location="/Login"

id="Intranet" isDefault="true" relayState="cookie"

entityID=" https://testidp.example.com/idp/shibboleth">

</SessionInitiator>

Still allows either protocol, but if the IdP supports Shibboleth profile of SAML 1, it will be used instead.

Discovery

Protocol SessionInitiators work when the IdP is known.

For consistency, discovery is implemented with alternate SessionInitiators that operate only when the IdP is NOT known.

A typical federated chain includes one or more "protocol" handlers followed by a single "discovery" handler at the end.

Typical Discovery Methods

External Options

older WAYF model, specific to Shibboleth/SAML1, SP loses control if a problem occurs

newer SAMLDS model, recently standardized, supports multiple SSO protocols and allows the SP to control the process

Internal Options

implemented by an application, followed by a redirect with the entityID

advanced "Cookie", "Form", and "Transform" SessionInitiators

DS Case

Multiple protocols, discovery via DS:

<SessionInitiator type="Chaining" Location="/DS"

id="DS" isDefault="true" relayState="cookie">

<SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>

<SessionInitiator type="SAMLDS" URL="https://ds.example.com/DS"/>

</SessionInitiator>

Same as intranet case, but omits entityID and adds a "safety net" at the bottom.

A bit sneaky: the DS handler tells the DS to return the user to this location with a lazy session redirect that will invoke an earlier handler in the chain.

Problems with External Discovery

Loss of control, UI fidelity

Impact of errors

Choice of IdPs becomes arbitrary: metadata errors have to be handled

Comprehensiveness is impossible in a world of multiple federations, and the list is too long if there's only one federation

Advanced SessionInitiators

Form SessionInitiator

Crude DS relying on HTML form template, NOT meant to replace the actual DS implementation.

Cookie SessionInitiator (early in chain)

Parses _saml_idp cookie maintained by idpHistory feature and sets entityID ahead of other handlers.

Transform SessionInitiator (early in chain)

Applies substitution or regex patterns against entityID to turn it into another entityID until metadata is available.

Advanced Example

Use a form to prompt for the entityID, or a domain name or email address that is input to a convention (https://testidp.domain/idp/shibboleth):

<SessionInitiator type="Chaining" Location="/DS"

id="DS" isDefault="true" relayState="cookie">

<SessionInitiator type="Transform">

<Subst>https://testidp.$entityID/idp/shibboleth</Subst>

<Regex match=".+@(.+)">https://testidp.$1/idp/shibboleth</Regex>

</SessionInitiator>

<SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/>

<SessionInitiator type="Form" template="discoveryTemplate.html"/>

</SessionInitiator>

END

SP Advanced Integration

Error Handling

Logout

Error Handling Approaches

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

Default is to output customizable templates divided into a couple of types of errors.

Templates written in HTML plus simple markup allowing information to be plugged in.

PLEASE customize these pages.

Optionally can redirect to a script on errors with parameters identifying the error.

Major use case: passive SSO failure.

Logout

Two types of sign-out operations: local and global.

Local logout affects only the SP (and possibly applications behind it).

Global logout includes the IdP and possibly other SPs sharing the session at the IdP.

Most global/single logout protocols can start at either end.

IdP-initiated Logout

Logout protocols that start at the IdP, such as SAML's, are implemented by SingleLogoutService handlers.

Details are dependent on the protocol, but generally will result in transfer back to the IdP regardless of the outcome.

SP-initiated Logout

Relies on a chain of handlers called LogoutInitiators.

Each handler understands a single SSO protocol and how to perform logout for it.

The "Local" handler typically runs if nothing else does, and performs a local sign-out operation, ignoring the IdP.

Application Notification

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

Applications can be notified when logout occurs by installing scripts to receive redirects or loopback XML messages.

Notifications allow applications to clean up their state before the SP cleans up its own.

END

SP Virtualization

Terminology

Adding a second vhost-based application

Clustering

HTTP virtualization

Terminology

Service Provider (physical)

an installation of the software on a server

Service Provider (logical)

web resources viewed externally as a unit

each entityID identifies exactly one logical SP

SP Application

web resources viewed internally as a unit

each applicationId identifies exactly one logical application

a user session is bound to exactly one application

Virtualization Concepts

A single physical SP can host any number of logical SPs. (virtual hosting)

A logical SP can then include any number of "applications".

Web virtual hosting is often related but is also independent.

Applications can inherit or override default configuration settings on a piecemeal basis.

Multiple physical SPs can also act as a single logical SP. (clustering)

Adding an Application

Goal: add a second application with its own entityID living on its own virtual host.

Add the application and map the host to it:

Line 55:

<RequestMap applicationId="default">

<Host applicationId="alt"/>

Line 243:

<ApplicationOverride id="alt" entityID="https://altsp N .example.com/shibboleth"/>

</ApplicationDefaults>

Clustering

Configure multiple physical installations to share an entityID, and possibly credentials.

Configuration files often can be identical across servers that share an external hostname.

Session management:

For applications already handling this, 2-3 minute sticky sessions usually sufficient.

SP itself now clusterable via ODBC, soon memcached.

HTTP Virtualization

Broadly, it's when the physical connection into a server has a different scheme, hostname, or port than the client sees.

Not all web servers actually support this!

"Support" means that the server's internal APIs allow an application to correctly construct an absolute redirect to itself.

HTTP Virtualization

The SP relies on the web server to be correctly configured.

Apache virtual host definitions allow the scheme, hostname, and port to be "overridden" from the physical values. You MUST do this if you expect the SP to work.

For servers without native support (i.e. IIS), the SP has "gap filling" features allowing the scheme, hostname, and port to be supplied on a per-site basis.

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

END

SP Relying Party Configuration

Philosophically, goal is to reduce or eliminate IdP-specific settings:

deployment profiles and best practices

uniform entityID and metadata

uniform credentials

Counter to this goal are federation-specific approaches to naming, certificates, and security requirements.

Using PKI across federations is a major impediment to SP deployment and interfederation.

Relying Party Settings

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

Most settings are security- or connectivity-related:

signing and encryption rules, algorithms

selecting among multiple keys or certificates

authentication types and connection timeouts for back-channel communications to IdPs

rules for signing or encryption imposed on messages from IdPs

Relying Party Selection

API to acquire settings is metadata-based and not as flexible as it should be

Primary matching based on IdP's entityID

Secondary matching proceeds up through any enclosing EntitiesDescriptor groups.

<md:EntitiesDescriptor Name="https://thefederation.com">

<md:EntitiesDescriptor Name="https://thefederation.com/group1">

<md:EntityDescriptor entityID="https://sp.example.com/shibboleth"/>

</md:EntitiesDescriptor>

</md:EntitiesDescriptor>

Credential Selection Example

Most common use case today.

With 2.0, credentials can be annotated with a name used when looking up the right set to use:

<ApplicationDefaults …>

…

<RelyingParty Name="https://theotherfederation.com" keyName="other"/>

…

<CredentialResolver type="Chaining">

<CredentialResolver type="File"

key="sp-key.pem" certificate="sp-cert.pem"/>

<CredentialResolver type="File" keyName="other"

key="sp-key.pem" certificate="other-cert.pem"/>

</CredentialResolver>

</ApplicationDefaults>

Complications

Settings can only be chosen based on the IdP once the IdP is known.

Sometimes settings needed in contexts in which the IdP is not known:

legacy WAYF model

SAML 2 Enhanced Client profile

Moral of the story: most settings simply shouldn't vary to avoid needless complexity.

END

Campus SSO Support

OSU Experiences

Pros

Cons

Strategies and Issues

OSU Deployment

Dates to 2004, accelerated deployment during 2005.

Migration from legacy software at 50+ departmental servers completed by March 2007.

Currently 141 locally registered SPs, server count closer to 100.

Two servers handle 80-130,000 logins/day.

0.4 FTE

Pros

Feature-rich without being fragile

Unified internal/external solution

Clusters/scales efficiently

Attribute support without requiring LDAP

Enforces proper application design

Cons

Certificates and XML

Lack of web server expertise

Enforcing entityID sanity

Crazy hosting practices

Zero-effort expectations

configuration effort, especially error handling

using support channels

metadata and software maintenance

Local Documentation

Put in a local context and set expectations

Pointers to support resources, preferably not your email address

Step by step process with starter files or a custom installer/package

metadata

routing requests to IdP

local attributes and conventions

error templates

Attributes, Attributes, Attributes

Precise definitions

Local semantics

Conventions for header names

Influence developer practices

Process

Certificate strategy: take advantage of 2.0 keypair generation

SP registration: manual or automated

IdP metadata: local vs. reuse of federation; understanding the security and operational issues

Policies for attribute release: avoiding "policy by sysadmin"

Awareness of updates and EOL timelines

Federation Implications

Few local services may be interested in federating, and few of those may be ready.

Local strategy needn't focus on it, but shouldn't preclude it either.

single IdP

use of federation metadata

federation-friendly design practices

InCommon simplifying process of federating existing sites without reissuing credentials.

Campus-level WAYF/DS quite sensible.

END

Federating Applications

Definitions

Policy or Wing It?

Authentication and Identifiers

Discovery

Introduction Problem

End User Support

Definitions

Federation of an application

Accepting identity attributes from multiple, distinct external sources that do not share a common identity namespace.

Protocol agnostic (relying on OpenID is federation).

Implies some degree of externalization, but much may be left internal.

Policy vs. Expediency

Address everything up front contractually or rely on remediation strategies through existing channels?

Level of Assurance

Formal means of assessing and articulating proofing, credentialing, and authentication processes.

Contrast with SSO within our organizations.

Contrast with non-federated alternatives.

Externalizing Authentication

Most visible, well understood part

Analagous to making SSO work locally

Consider the cost of limiting the application to a single federation protocol

Consider dynamic provisioning of identities at the time of login

Identifiers

Must determine application requirements for different kinds of identifiers.

Assumptions on length, character set fall apart in a federated model.

Lots of subtleties:

uniqueness

persistence

reassignment

human readability

social knowledge

Common Identifiers

local userid/netid

usually readable, persistent but not permanent, often reassigned, not unique

email address

usually readable, persistent but not permanent, often reassigned, unique

eduPersonPrincipalName

usually readable, persistent but not permanent, can be reassigned, unique

eduPersonTargetedID / SAML 2.0 persistent ID

not readable, semi-permanent, not reassigned, unique

OpenID

usually somewhat readable, usually persistent, may be reassignable, unique

eduPersonTargetedID

Legacy attribute placeholder for the SAML 2.0 persistent NameID format:

opaque

pairwise (IdP/SP, could be shared by >1 SP)

original motivation was privacy, but strongest features are lack of reassignment and immunity to name changes

<saml:NameID

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"

NameQualifier="https://testidp.example.com/idp/shibboleth"

SPNameQualifier="https://testsp.example.com/shibboleth"

>anystringthatcouldbeup256chars</saml:NameID>

https://testidp.example.com/idp/shibboleth!https://testsp.example.com/shibboleth!anystringthatcouldbeup256chars

eduPersonTargetedID

Minimally supported so far:

not easily stored in LDAP

can be generated from a hash, but with drawbacks:

value tied to inputs (underlying userid, name of SP)

can't be refreshed to maintain privacy

hard to reverse efficiently

ideally generated randomly and stored and managed in a database, but adds state and additional backup requirements to IdP

Discovery

Two kinds of applications:

relatively balanced audience across IdPs

overweighted to a single IdP with a few outliers

Most campus applications are the latter, making discovery a usability issue (or so some argue).

Easy solution is also a poor one:

"Click here if you're not from Foobar U"

I'll happily phish your users, just don't do it to mine

More pronounced with federation, but can arise with SSO alone.

Traditional apps have access to their entire user population in advance.

Assigning roles or adding access involves a "people picker".

There is no federated people picker, and privacy limits the ability to build one in the general sense.

Basic use case:

I want to add person X to a group or give them to access a resource.

What is X? Can it be known in advance? If not, is strong security even possible?

Next major problem frontier.

End User Support

Supporting a federated application from the IdP side is a dead end (e.g. OpenID).

Applications MUST provide adequate feedback to users and prepare their support staff for the change.

I argue they also must own access issues even if they ultimately get blamed on the IdP, or federation will never scale.

END

SAML Metadata

Scope

Terminology

Migration Support

Trust Management

Identity Provider Metadata

Service Provider Metadata

Scope

Entities in hierarchical groups

Peer roles and protocol support

Profile support and endpoint locations

Advertising extension support

Trust management

Encryption keys

Attribute support and requirements

Contact information

Scope

Not in Scope:

Authorization policy

Security policy

Maybe in Scope:

Federation-asserted attributes about members

Profiles for non-SAML protocol families

Other Relevancies

WS-Federation metadata proposals

WS-MetadataExchange

XRI and XRDS (used by OpenID)

DNSSEC, SRV records

Terminology

EntityDescriptor

A distinct SAML-supporting system, can be collected into EntitiesDescriptor groups.

Role

A SAML functional role played by a system (IdP, SP, AA, PDP, etc.)

Protocol

A set of profiles grouped into a single "family" (SAML 1.0, SAML 1.1, SAML 2.0, etc.)

Endpoint

A descriptor identifying how to invoke a service supporting a particular profile.

KeyDescriptor

A signing or encryption key, underspecified syntax.

Supporting Migration

Metadata use backported to SAML 1.1 by Shibboleth project, standardized at OASIS.

Entity roles tagged with supported protocols, allowing new protocols to be added without affecting existing deployments.

Supports multiple keys for key rollover.

Trust Management

Agreement

Vehicle for communicating who can be trusted and how to establish that trust at a technical level.

Less Agreement

How to communicate trust and whether to do so absent additional infrastructure.

Aggregation of metadata.

Generally: peer to peer vs. additional PKI

Trust Management

Shibboleth Implementation and Goals

Produce a well-documented and understandable set of approaches accomodating different communities.

Pursue a disaggregation of PKI from the SAML runtime to enable federation to scale without a global PKI.

Collaborate with vendors on profiles to standardize approaches.

Identity Provider Metadata

Typically include IdP and AA roles, reflecting attribute query use in Shibboleth

Endpoints for SSO requests, queries, logout, advanced SAML profiles

Signing/encryption keys

Supported NameID formats, Attributes

Contact information

Proposal made to carry organization logos

Service Provider Metadata

Role representing notion of a SAML-enabled web site supporting SSO profiles

Endpoints for SSO responses, logout, advanced SAML profiles

Signing/encryption keys

Supported NameID formats

Rudimentary support for expressing "service levels" and attribute requirements

Contact information

Shibboleth 2.0 SP slides - Installfest

0 comments

Notes on slide 1

1 Favorite