Shibboleth 2.0 SP slides - Installfest

Shibboleth 2.0 InstallFestService Provider MaterialShibboleth 2.0 InstallFestService Provider Material

May 2008Ann Arbor, MI

May 2008Ann Arbor, MI

SP Overview and InstallationSP Overview and Installation

• Bearings and Terminology

• Installation and Directory Structure

• Generating Key and Certificate

• Picking an entityID

• Initial Configuration

• Testing

2

System EnvironmentSystem 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:• spN.example.com• altspN.example.com (later)

3

TerminologyTerminology

• 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

4

InstallationInstallation

• 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

5

Sanity ChecksSanity 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://spN.example.com/Shibboleth.sso/Session

• Intentionally trigger an error from browser:https://spN.example.com/Shibboleth.sso/Foo

6

https://localhost/Shibboleth.sso/Status

https://spn.example.com/Shibboleth.sso/Session

https://spn.example.com/Shibboleth.sso/Session

https://spn.example.com/Shibboleth.sso/Foo

https://spn.example.com/Shibboleth.sso/Foo

BinariesBinaries

• /usr/sbin/shibd

• /usr/bin/resolvertest

• /usr/bin/mdquery

• /usr/lib/shibboleth/*.so• Apache/etc. modules, SP extensions

7

Supporting FilesSupporting 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)

8

Key/Certificate GenerationKey/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/spN/sp.key /etc/shibboleth/sp-key.pem

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

9

Picking an entityIDPicking an entityID

• How NOT to do it (but we’re doing it anyway):• https://spN.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

10

https://spn.example.com/shibboleth

https://spn.example.com/shibboleth

Bootstrapping the SPBootstrapping 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 spN.example.com

11

Bootstrapping the SP (cont.)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://spN.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"/>

12

Bootstrapping the SP (cont.)Bootstrapping the SP (cont.)

• Provide metadata remotely from test IdP:$ vi /etc/shibboleth/shibboleth2.xmlLine 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

13

https://spn.example.com/Shibboleth.sso/Metadata

Testing the SPTesting the SP

• Try it with a browser:https://spN.example.com/cgi-bin/test

• Dump your session:https://spN.example.com/Shibboleth.sso/Session

14

Logging OutLogging Out

• To logout locally from the SP and kill your session:https://spN.example.com/Shibboleth.sso/Logout

• Or just close the browser and start over.

15

Trying your own IdPTrying your own IdP

• Adjust SessionInitiator and add metadata for your IdP to your SP:$ vi /etc/shibboleth/shibboleth2.xmlLine 105:<SessionInitiator type="Chaining" Location="/Login"

isDefault="true" id="Intranet" relayState="cookie" entityID="https://idpN.example.com/idp/shibboleth">

Line 208:<MetadataProvider type="Chaining">

<MetadataProvider type="XML"path="/opt/installfest/idpN/idpN-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="SPN" xsi:type="FilesystemMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"

metadataFile="/opt/installfest/spN/spN-metadata.xml"/>16

TestingTesting

• Restart Tomcat (and the IdP)$ /etc/init.d/tomcat stop

$ ps –ef | grep java

$ /etc/init.d/tomcat restart

• Try it with a browser:https://spN.example.com/cgi-bin/test

• Dump your session:https://spN.example.com/Shibboleth.sso/Session

17

Use a Discovery ServiceUse a Discovery Service

• Use a discovery service by changing the default SessionInitiator:$ vi /etc/shibboleth/shibboleth2.xmlLine 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>

18

Lazy SessionsLazy 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.

19

Using Lazy SessionsUsing 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.

20

Session Creation ParametersSession 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

21

Lazy Session ExampleLazy Session Example

• Access unprotected script:https://spN.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://idpN.example.com/idp/shibboleth

22

END

23

SP Basic ConfiguratonSP Basic Configuraton

• Summary of Files

• Structure of Master Configuration

• Changing Logging Levels

• Metadata

• .htaccess

• RequestMap

• Handlers

24

Configuration Files/etc/shibbolethConfiguration 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

25

shibboleth2.xml Structureshibboleth2.xml Structure

• <OutOfProcess> / <InProcess>

• <UnixListener> / <TCPListener>

• <StorageService>• <SessionCache>• <ReplayCache>• <ArtifactMap>

• <RequestMapper>

• <ApplicationDefaults>

• <SecurityPolicies> 26

shibboleth2.xml Structureshibboleth2.xml Structure

• <ApplicationDefaults>• <Sessions>• <Errors>• <RelyingParty> (*)• <MetadataProvider>• <TrustEngine>• <AttributeExtractor>• <AttributeResolver>• <AttributeFilter>• <CredentialResolver>• <ApplicationOverride> (*)

27

LoggingLogging

• 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

28

Logging: Tracing MessagesLogging: Tracing Messages

• Raise categories:$ vi shibd.logger

Line 14:# tracing of SAML messages and security policieslog4j.category.OpenSAML.MessageDecoder=DEBUGlog4j.category.OpenSAML.MessageEncoder=DEBUGlog4j.category.OpenSAML.SecurityPolicyRule=DEBUG

• To implement *.logger changes:$ touch shibboleth2.xml$ tail -f /var/log/shibboleth/shibd.log

• Test the SP again:https://spN.example.com/cgi-bin/test

29

SP Metadata FeaturesSP 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

30

Signature VerificationSignature Verification

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

• First, "break" it:$ vi /etc/shibboleth/shibboleth2.xml

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>

31

Signature VerificationSignature Verification

• Now preinstall the right signing key:$ cd /etc/shibboleth

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

• Then fix it:$ vi /etc/shibboleth/shibboleth2.xml

Line 208:


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

<SignatureMetadataFilter certificate="idp.crt"/>

</MetadataProvider>

32

Content SettingsContent 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://spN.example.com/cgi-bin/content

33

.htaccess Examples.htaccess Examples

• Requiring authentication:$ vi /var/www/cgi-bin/.htaccess

AuthType shibboleth

require shibboleth

ShibRequestSetting requireSession 1

34


• Auto-redirecting to SSL:$ vi /var/www/cgi-bin/.htaccess

AuthType shibboleth

require shibboleth


ShibRequestSetting redirectToSSL 443

35


• Bypassing SSO:$ vi /var/www/cgi-bin/.htaccess

AuthType shibboleth

require shibboleth


ShibRequestSetting forceAuthn 1

36

RequestMap ExamplesRequestMap Examples

• Make sure .htaccess is in its original state.

• Requiring authentication:$ vi /etc/shibboleth/shibboleth2.xml

Line 62:

<Host name="spN.example.com">

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

requireSession="true"/>

</Host>

37

RequestMap FragilityRequestMap 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://altspN.example.com/cgi-bin/content

• How to fix?vi /etc/httpd/conf/httpd.conf

UseCanonicalName On38


• Auto-redirecting to SSL:$ vi /etc/shibboleth/shibboleth2.xml

Line 62:



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

</Host>

39


• Bypassing SSO:$ vi /etc/shibboleth/shibboleth2.xml

Line 62:



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

</Host>

40

Other Content SettingsOther Content Settings

• Requesting types of authentication

• Error handling pages

• Redirection-based error handling

• isPassive

• Supplying a specific IdP to use

41

SP HandlersSP 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)

42

SP HandlersSP 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.43

Some Handler OptionsSome Handler Options

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

• Remove relayState to pass URLs by value.$ vi /etc/shibboleth/shibboleth2.xml



44


• Switch to Artifact binding for response:$ vi /etc/shibboleth/shibboleth2.xml



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

45


• Switch from SAML 2 Redirect to POST:$ vi /etc/shibboleth/shibboleth2.xml

Line 105:<SessionInitiator type="Chaining" Location="/Login" isDefault="true"

id="Intranet" relayState="cookie" entityID="https://testidp.example.com/idp/shibboleth">

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

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

46

END

47

SP Attribute HandlingSP Attribute Handling

• Terminology

• Scoped Attributes

• Adding New Attribute Mappings

• REMOTE_USER and Identifiers

• Filtering Overview

• Source-Based Filtering

• Access Control

48

SP Attribute TerminologySP 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)49

Scoped AttributesScoped 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".

50

Attribute MappingsAttribute 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.

51

Dissecting an attribute ruleDissecting 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)

52

Adding mappingsAdding 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.

53

REMOTE_USERREMOTE_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.

54

Changing REMOTE_USERChanging REMOTE_USER

• Put the "sn" attribute into REMOTE_USER:$ vi /etc/shibboleth/shibboleth2.xml

Line 80:

REMOTE_USER="sn eppn"

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

55

Attribute FilteringAttribute 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 [email protected])

• limiting custom attributes to particular sources

56

Default PolicyDefault 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.

57

Add a Source-Based RuleAdd 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://idpN.example.com/idp/shibboleth"/>

</afp:AttributeRule>

58

Access ControlAccess 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

59

.htaccess Access Control.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

60

.htaccess Example.htaccess Example

• Require an entitlement or specific users:$ vi /var/www/cgi-bin/.htaccess

AuthType shibboleth


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

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

61

XML Access ControlXML 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>).

62

XML ExampleXML Example

• Require an entitlement or specific users:$ vi /etc/shibboleth/shibboleth2.xml

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>

63

END

64

Session Initiators / DiscoverySession Initiators / Discovery

• Concepts

• Chains and protocol precedence

• Lazy sessions

• Discovery services

• Internal discovery mechanisms

65

Session Initiators / DiscoveryConceptsSession Initiators / DiscoveryConcepts

• 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

66

Simplest CaseSimplest 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.

67

Intranet CaseIntranet 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 type="SAML2" defaultACSIndex="1"

template="bindingTemplate.html"/><SessionInitiator type="Shib1" defaultACSIndex="5"/>

</SessionInitiator>

• Protocol precedence controlled by order of chain.

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

68

Favoring Legacy ProtocolFavoring Legacy Protocol

• Switch order of chain:$ vi /etc/shibboleth/shibboleth2.xmlLine 105:<SessionInitiator type="Chaining" Location="/Login"

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

https://testidp.example.com/idp/shibboleth"><SessionInitiator type="Shib1" defaultACSIndex="5"/><SessionInitiator type="SAML2" defaultACSIndex="1"

template="bindingTemplate.html"/></SessionInitiator>

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

69

DiscoveryDiscovery

• 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.

70

Typical Discovery MethodsTypical 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

71

DS CaseDS 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="Shib1" defaultACSIndex="5"/><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.

72

Problems with External DiscoveryProblems 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

73

Advanced SessionInitiatorsAdvanced 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.

74

Advanced ExampleAdvanced 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="Shib1" defaultACSIndex="5"/>

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

</SessionInitiator>

75

END

76

SP Advanced IntegrationSP Advanced Integration

• Error Handling

• Logout

77

Error Handling ApproachesError 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.

78

LogoutLogout

• 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.

79

IdP-initiated LogoutIdP-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.

80

SP-initiated LogoutSP-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.

81

Application NotificationApplication 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.

82

END

83

SP VirtualizationSP Virtualization

• Terminology

• Adding a second vhost-based application

• Clustering

• HTTP virtualization

84


• 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

85

Virtualization ConceptsVirtualization 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)

86

Adding an ApplicationAdding 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:$ vi /etc/shibboleth/shibboleth2.xml

Line 55:

<RequestMap applicationId="default">

<Host applicationId="alt"/>

Line 243:

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

</ApplicationDefaults>

87

ClusteringClustering

• 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.

88

HTTP VirtualizationHTTP 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.

89

HTTP VirtualizationHTTP 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

90

END

91

SP Relying Party ConfigurationSP 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.

92

Relying Party SettingsRelying 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

93

Relying Party SelectionRelying 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>

94

Credential Selection ExampleCredential 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>

95

ComplicationsComplications

• 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.

96

END

97

Campus SSO SupportCampus SSO Support

• OSU Experiences

• Pros

• Cons

• Strategies and Issues

98

OSU DeploymentOSU 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

99

ProsPros

• Feature-rich without being fragile

• Unified internal/external solution

• Clusters/scales efficiently

• Attribute support without requiring LDAP

• Enforces proper application design

100

ConsCons

• 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

101

Local DocumentationLocal 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

102

Attributes, Attributes, AttributesAttributes, Attributes, Attributes

• Precise definitions

• Local semantics

• Conventions for header names

• Influence developer practices

103

ProcessProcess

• 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 timelines104

Federation ImplicationsFederation 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.105

END

106

Federating ApplicationsFederating Applications

• Definitions

• Policy or Wing It?

• Authentication and Identifiers

• Discovery

• Introduction Problem

• End User Support

107

DefinitionsDefinitions

• 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.

108

Policy vs. ExpediencyPolicy 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.

109

Externalizing AuthenticationExternalizing 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

110

IdentifiersIdentifiers

• 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

111

Common IdentifiersCommon 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

112

eduPersonTargetedIDeduPersonTargetedID

• 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:NameIDFormat="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

113

eduPersonTargetedIDeduPersonTargetedID

• 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

114

DiscoveryDiscovery

• 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

115

Introduction ProblemIntroduction Problem

• 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.

116

Introduction ProblemIntroduction Problem

• 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.

117

End User SupportEnd 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.

118

END

119

SAML MetadataSAML Metadata

• Scope

• Terminology

• Migration Support

• Trust Management

• Identity Provider Metadata

• Service Provider Metadata

120

ScopeScope

• 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 information121

ScopeScope

• Not in Scope:• Authorization policy• Security policy

• Maybe in Scope:• Federation-asserted attributes about members• Profiles for non-SAML protocol families

122

Other RelevanciesOther Relevancies

• WS-Federation metadata proposals

• WS-MetadataExchange

• XRI and XRDS (used by OpenID)

• DNSSEC, SRV records

123


• 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.

124

Supporting MigrationSupporting 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.

125

Trust ManagementTrust 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 PKI126

Trust ManagementTrust 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.

127

Identity Provider MetadataIdentity 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

128

Service Provider MetadataService 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

129

Technology

Shibboleth 2.0 SP slides - Installfest