Shibboleth 2.0 SP slides - Installfest
-
Upload
jiscam -
Category
Technology
-
view
9.087 -
download
5
description
Transcript of 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
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
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
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="Chaining">
<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="Chaining">
<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
.htaccess Examples.htaccess Examples
• Auto-redirecting to SSL:$ vi /var/www/cgi-bin/.htaccess
AuthType shibboleth
require shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting redirectToSSL 443
35
.htaccess Examples.htaccess Examples
• Bypassing SSO:$ vi /var/www/cgi-bin/.htaccess
AuthType shibboleth
require shibboleth
ShibRequestSetting requireSession 1
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
RequestMap ExamplesRequestMap Examples
• Auto-redirecting to SSL:$ vi /etc/shibboleth/shibboleth2.xml
Line 62:
<Host name="spN.example.com">
<Path name="cgi-bin" authType="shibboleth"
requireSession="true" redirectToSSL="443"/>
</Host>
39
RequestMap ExamplesRequestMap Examples
• Bypassing SSO:$ vi /etc/shibboleth/shibboleth2.xml
Line 62:
<Host name="spN.example.com">
<Path name="cgi-bin" authType="shibboleth"
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
Line 105:<SessionInitiator type="Chaining" Location="/Login"
isDefault="true" id="Intranet" relayState="cookie" entityID="https://testidp.example.com/idp/shibboleth">
44
Some Handler OptionsSome Handler Options
• Switch to Artifact binding for response:$ 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="2" template="bindingTemplate.html"/>
45
Some Handler OptionsSome Handler Options
• 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
ShibRequestSetting requireSession 1
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:
<Host name="spN.example.com">
<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
TerminologyTerminology
• 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
TerminologyTerminology
• 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