Shibboleth 2'0 InstallFest Service Provider Material

1
Shibboleth 2.0 InstallFestService Provider
Material

• May 2008
• Ann Arbor, MI

2
SP Overview and Installation

• Bearings and Terminology
• Installation and Directory Structure
• Generating Key and Certificate
• Picking an entityID
• Initial Configuration
• Testing

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

4
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

5
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

6
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//spN.example.com/Shibboleth.sso/Session
• Intentionally trigger an error from browser
• https//spN.example.com/Shibboleth.sso/Foo

7
Binaries

• /usr/sbin/shibd
• /usr/bin/resolvertest
• /usr/bin/mdquery
• /usr/lib/shibboleth/.so
• Apache/etc. modules, SP extensions

8
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)

9
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/spN/sp.key
  /etc/shibboleth/sp-key.pem
• cp /opt/installfest/spN/sp.crt
  /etc/shibboleth/sp-cert.pem

10
Picking an entityID

• How NOT to do it (but were 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

11
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 spN.example.com

12
Bootstrapping the SP (cont.)

• Relax some requirements and set your entityID and
  the IdPs entityID.
• vi /etc/shibboleth/shibboleth2.xml
• Line 6 (Do NOT do this in production)
• logger"syslog.logger" clockSkew"180000"gt
• Line 77
• ltApplicationDefaults id"default"
  policyId"default" entityID"https//spN.example.c
  om/shibboleth"gt
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"true" id"Intranet"
  relayState"cookie" entityID"https//testidp.exam
  ple.com/idp/shibboleth"gt
• Line 184
• ltHandler type"Session" Location"/Session"
  showAttributeValues"true"/gt

13
Bootstrapping the SP (cont.)

• Provide metadata remotely from test IdP
• vi /etc/shibboleth/shibboleth2.xml
• Line 208
• ltMetadataProvider type"Chaining"gt
• ltMetadataProvider type"XML" url"https//testidp.
  example.com/testidp-metadata.xml"
  backingFilePath"testidp-metadata.xml"
  reloadInterval"3600"/gt
• Supply metadata to parties of interest. (done for
  you)
• curl -k https//spN.example.com/Shibboleth.sso/M
  etadata

14
Testing the SP

• Try it with a browser
• https//spN.example.com/cgi-bin/test
• Dump your session
• https//spN.example.com/Shibboleth.sso/Session

15
Logging 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.

16
Trying your own IdP

• Adjust SessionInitiator and add metadata for your
  IdP to your SP
• vi /etc/shibboleth/shibboleth2.xml
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"true" id"Intranet"
  relayState"cookie" entityID"https//idpN.example
  .com/idp/shibboleth"gt
• Line 208
• ltMetadataProvider type"Chaining"gt
• ltMetadataProvider type"XML"path"/opt/installfes
  t/idpN/idpN-metadata.xml"/gt
• Add metadata for your SP to your IdP
• vi /opt/shibboleth-idp/conf/relying-party.xml
• ltMetadataProvider id"ShibbolethMetadata"
  xsitype"ChainingMetadataProvider"
  xmlns"urnmaceshibboleth2.0metadata"gt
• ltMetadataProvider id"SPN" xsitype"FilesystemMe
  tadataProvider" xmlns"urnmaceshibboleth2.0met
  adata"
• metadataFile"/opt/installfest/spN/spN-metada
  ta.xml"/gt

17
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
• https//spN.example.com/cgi-bin/test
• Dump your session
• https//spN.example.com/Shibboleth.sso/Session

18
Use a Discovery Service

• Use a discovery service by changing the default
  SessionInitiator
• vi /etc/shibboleth/shibboleth2.xml
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"false" id"Intranet"
  relayState"cookie"
• Line 119
• ltSessionInitiator type"Chaining" Location"/DS"
  id"DS" relayState"cookie" isDefault"true"
  acsByIndex"false"gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" /gt
• ltSessionInitiator type"Shib1"
  defaultACSIndex"5"/gt
• ltSessionInitiator type"SAMLDS"
  URL"https//ds.example.com/DS/WAYF"/gt
• lt/SessionInitiatorgt

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

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

21
Session Creation Parameters

• https//spaces.internet2.edu/display/SHIB2/NativeS
  PSessionCreationParameters
• 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)
• ltSessionInitiatorgt element

22
Lazy 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/contenten
  tityIDhttps//idpN.example.com/idp/shibboleth

23

• END

24
SP Basic Configuraton

• Summary of Files
• Structure of Master Configuration
• Changing Logging Levels
• Metadata
• .htaccess
• RequestMap
• Handlers

25
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

26
shibboleth2.xml Structure

• ltOutOfProcessgt / ltInProcessgt
• ltUnixListenergt / ltTCPListenergt
• ltStorageServicegt
• ltSessionCachegt
• ltReplayCachegt
• ltArtifactMapgt
• ltRequestMappergt
• ltApplicationDefaultsgt
• ltSecurityPoliciesgt

27
shibboleth2.xml Structure

• ltApplicationDefaultsgt
• ltSessionsgt
• ltErrorsgt
• ltRelyingPartygt ()
• ltMetadataProvidergt
• ltTrustEnginegt
• ltAttributeExtractorgt
• ltAttributeResolvergt
• ltAttributeFiltergt
• ltCredentialResolvergt
• ltApplicationOverridegt ()

28
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

29
Logging Tracing Messages

• Raise categories
• vi shibd.logger
• Line 14
• tracing of SAML messages and security policies
• log4j.category.OpenSAML.MessageDecoderDEBUG
• log4j.category.OpenSAML.MessageEncoderDEBUG
• log4j.category.OpenSAML.SecurityPolicyRuleDEBUG
• 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

30
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

31
Signature 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
• ltMetadataProvider type"Chaining"gt
• ltMetadataProvider type"XML" url"https//testidp.
  example.com/testidp-metadata.xml"
  backingFilePath"testidp-metadata.xml"
  reloadInterval"3600"gt
• ltSignatureMetadataFilter certificate"sp-cert.pem
  "/gt
• lt/MetadataProvidergt

32
Signature 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
• ltMetadataProvider type"Chaining"gt
• ltMetadataProvider type"XML" url"https//testidp.
  example.com/testidp-metadata.xml"
  backingFilePath"testidp-metadata.xml"
  reloadInterval"3600"gt
• ltSignatureMetadataFilter certificate"idp.crt"/gt
• lt/MetadataProvidergt

33
Content Settings

• https//spaces.internet2.edu/display/SHIB2/NativeS
  PContentSettings
• 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

34
.htaccess Examples

• Requiring authentication
• vi /var/www/cgi-bin/.htaccess
• AuthType shibboleth
• require shibboleth
• ShibRequestSetting requireSession 1

35
.htaccess Examples

• Auto-redirecting to SSL
• vi /var/www/cgi-bin/.htaccess
• AuthType shibboleth
• require shibboleth
• ShibRequestSetting requireSession 1
• ShibRequestSetting redirectToSSL 443

36
.htaccess Examples

• Bypassing SSO
• vi /var/www/cgi-bin/.htaccess
• AuthType shibboleth
• require shibboleth
• ShibRequestSetting requireSession 1
• ShibRequestSetting forceAuthn 1

37
RequestMap Examples

• Make sure .htaccess is in its original state.
• Requiring authentication
• vi /etc/shibboleth/shibboleth2.xml
• Line 62
• ltHost name"spN.example.com"gt
• ltPath name"cgi-bin" authType"shibboleth"
• requireSession"true"/gt
• lt/Hostgt

38
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//altspN.example.com/cgi-bin/content
• How to fix?
• vi /etc/httpd/conf/httpd.conf
• UseCanonicalName On

39
RequestMap Examples

• Auto-redirecting to SSL
• vi /etc/shibboleth/shibboleth2.xml
• Line 62
• ltHost name"spN.example.com"gt
• ltPath name"cgi-bin" authType"shibboleth"
• requireSession"true" redirectToSSL"443"/gt
• lt/Hostgt

40
RequestMap Examples

• Bypassing SSO
• vi /etc/shibboleth/shibboleth2.xml
• Line 62
• ltHost name"spN.example.com"gt
• ltPath name"cgi-bin" authType"shibboleth"
• requireSession"true" forceAuthn"true"/gt
• lt/Hostgt

41
Other Content Settings

• Requesting types of authentication
• Error handling pages
• Redirection-based error handling
• isPassive
• Supplying a specific IdP to use

42
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)

43
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.exampl
  e.com/Shibboleth.sso/Login
• Handlers arent 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.

44
Some 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
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"true" id"Intranet"
  relayState"cookie" entityID"https//testidp.exam
  ple.com/idp/shibboleth"gt

45
Some Handler Options

• Switch to Artifact binding for response
• vi /etc/shibboleth/shibboleth2.xml
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"true" id"Intranet"
  relayState"cookie" entityID"https//testidp.exam
  ple.com/idp/shibboleth"gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"2" template"bindingTemplate.htm
  l"/gt

46
Some Handler Options

• Switch from SAML 2 Redirect to POST
• vi /etc/shibboleth/shibboleth2.xml
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login" isDefault"true" id"Intranet"
  relayState"cookie" entityID"https//testidp.exam
  ple.com/idp/shibboleth"gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" template"bindingTemplate.htm
  l"
• outgoingBindings"urnoasisnamestcSAML2.0bi
  ndingsHTTP-POST"/gt

47

• END

48
SP Attribute Handling

• Terminology
• Scoped Attributes
• Adding New Attribute Mappings
• REMOTE_USER and Identifiers
• Filtering Overview
• Source-Based Filtering
• Access Control

49
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)

50
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".

51
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 gt 1 "id" and multiple
  attributes can be mapped to the same "id".
• Decoders are attribute-independent but
  syntax-dependent.

52
Dissecting an attribute rule

• ltAttribute id"affiliation" aliases"affil"
• name"urnmacedirattribute-defeduPersonScoped
  Affiliation"gt
• ltAttributeDecoder xsitype"ScopedAttributeDeco
  der"
• caseSensitive"false"/gt
• lt/Attributegt
• 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 xsitype
• decoder plugin to use (defaults to simple/string)
• caseSensitive
• how to compare values at runtime (defaults to
  true)

53
Adding mappings

• Add first and last name for both SAML 1 and SAML
  2
• vi /etc/shibboleth/attribute-map.xml
• ltAttribute name"urnmacedirattribute-defsn"
  id"sn"/gt
• ltAttribute name"urnmacedirattribute-defgivenN
  ame" id"givenName"/gt
• ltAttribute name"urnoid2.5.4.4" id"sn"/gt
• ltAttribute name"urnoid2.5.4.42"
  id"givenName"/gt
• Takes effect immediately but NOT for any existing
  sessions.

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

55
Changing 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.

56
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_at_umich.edu)
• limiting custom attributes to particular sources

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

58
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
• ltafpAttributeRule attributeID"sn"gt
• ltafpPermitValueRule xsitype"AttributeIssuerStr
  ing" value"https//idpN.example.com/idp/shibbole
  th"/gt
• lt/afpAttributeRulegt

59
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

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

61
.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(12)_at_example.com

62
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 (ltANDgt,ltORgt,ltNOTgt).

63
XML Example

• Require an entitlement or specific users
• vi /etc/shibboleth/shibboleth2.xml
• Line 62
• ltHost name"spN.example.com"gt
• ltPath name"cgi-bin" authType"shibboleth"
  requireSession"true"gt
• ltAccessControlgt
• ltORgt
• ltRule require"entitlement"gt
  http//channel8.msdn.com/userlt/Rulegt
• ltRuleRegex require"user"gtstaff(12)_at_exam
  ple.comlt/RuleRegexgt
• lt/ORgt
• lt/AccessControlgt
• lt/Pathgt
• lt/Hostgt

64

• END

65
Session Initiators / Discovery

• Concepts
• Chains and protocol precedence
• Lazy sessions
• Discovery services
• Internal discovery mechanisms

66
Session 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

67
Simplest Case

• Single IdP, single protocol, no discovery
• ltSessionInitiator
• type"SAML2" id"simple" isDefault"true"
• Location"/Login"
• entityID"https//testidp.example.com/idp/shibbol
  eth"
• relayState"cookie"
• defaultACSIndex"1"
• template"bindingTemplate.html"
• /gt
• Resembles the typical approach used in 1.3 SP but
  omits hardcoding the IdP's location.

68
Intranet Case

• Single IdP, multiple protocols, no discovery
• ltSessionInitiator type"Chaining"
  Location"/Login"
• id"Intranet" isDefault"true"
  relayState"cookie"
• entityID" https//testidp.example.com/idp/shibb
  oleth"gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" template"bindingTemplate.h
  tml"/gt
• ltSessionInitiator type"Shib1"
  defaultACSIndex"5"/gt
• lt/SessionInitiatorgt
• Protocol precedence controlled by order of chain.
• Common properties defined at the top and
  inherited by chain links.

69
Favoring Legacy Protocol

• Switch order of chain
• vi /etc/shibboleth/shibboleth2.xml
• Line 105
• ltSessionInitiator type"Chaining"
  Location"/Login"
• id"Intranet" isDefault"true"
  relayState"cookie"
• entityID" https//testidp.example.com/idp/shibb
  oleth"gt
• ltSessionInitiator type"Shib1"
  defaultACSIndex"5"/gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" template"bindingTemplate.h
  tml"/gt
• lt/SessionInitiatorgt
• Still allows either protocol, but if the IdP
  supports Shibboleth profile of SAML 1, it will be
  used instead.

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

71
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

72
DS Case

• Multiple protocols, discovery via DS
• ltSessionInitiator type"Chaining" Location"/DS"
• id"DS" isDefault"true" relayState"cookie"gt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" acsByIndex"false"
  template"bindingTemplate.html"/gt
• ltSessionInitiator type"Shib1"
  defaultACSIndex"5"/gt
• ltSessionInitiator type"SAMLDS"
  URL"https//ds.example.com/DS"/gt
• lt/SessionInitiatorgt
• 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.

73
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

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

75
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)
  
• ltSessionInitiator type"Chaining" Location"/DS"
• id"DS" isDefault"true" relayState"cookie"gt
• ltSessionInitiator type"Transform"gt
• ltSubstgthttps//testidp.entityID/idp/shibbolethlt
  /Substgt
• ltRegex match"._at_(.)"gthttps//testidp.1/idp/sh
  ibbolethlt/Regexgt
• lt/SessionInitiatorgt
• ltSessionInitiator type"SAML2"
  defaultACSIndex"1" acsByIndex"false"
  template"bindingTemplate.html"/gt
• ltSessionInitiator type"Shib1"
  defaultACSIndex"5"/gt
• ltSessionInitiator type"Form" template"discovery
  Template.html"/gt
• lt/SessionInitiatorgt

76

• END

77
SP Advanced Integration

• Error Handling
• Logout

78
Error Handling Approaches

• https//spaces.internet2.edu/display/SHIB2/NativeS
  PErrors
• 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.

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

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

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

82
Application Notification

• https//spaces.internet2.edu/display/SHIB2/NativeS
  PNotify
• 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.

83

• END

84
SP Virtualization

• Terminology
• Adding a second vhost-based application
• Clustering
• HTTP virtualization

85
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

86
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)

87
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
• vi /etc/shibboleth/shibboleth2.xml
• Line 55
• ltRequestMap applicationId"default"gt
• ltHost applicationId"alt"/gt
• Line 243
• ltApplicationOverride id"alt" entityID"https//a
  ltspN.example.com/shibboleth"/gt
• lt/ApplicationDefaultsgt

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

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

90
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/NativeS
  PISAPI

91

• END

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

93
Relying Party Settings

• https//spaces.internet2.edu/display/SHIB2/NativeS
  PRelyingParty
• Most settings are security- or connectivity-relate
  d
• 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

94
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.
• ltmdEntitiesDescriptor Name"https//thefederation
  .com"gt
• ltmdEntitiesDescriptor Name"https//thefederatio
  n.com/group1"gt
• ltmdEntityDescriptor entityID"https//sp.exampl
  e.com/shibboleth"/gt
• lt/mdEntitiesDescriptorgt
• lt/mdEntitiesDescriptorgt

95
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
• ltApplicationDefaults gt
• ltRelyingParty Name"https//theotherfederation.co
  m" keyName"other"/gt
• ltCredentialResolver type"Chaining"gt
• ltCredentialResolver type"File"
• key"sp-key.pem" certificate"sp-cert.pem"/gt
• ltCredentialResolver type"File" keyName"other"
• key"sp-key.pem" certificate"other-cert.pem"/gt
  
• lt/CredentialResolvergt
• lt/ApplicationDefaultsgt

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

97

• END

98
Campus SSO Support

• OSU Experiences
• Pros
• Cons
• Strategies and Issues

99
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

100
Pros

• Feature-rich without being fragile
• Unified internal/external solution
• Clusters/scales efficiently
• Attribute support without requiring LDAP
• Enforces proper application design

101
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

102
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

103
Attributes, Attributes, Attributes

• Precise definitions
• Local semantics
• Conventions for header names
• Influence developer practices

104
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

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

106

• END

107
Federating Applications

• Definitions
• Policy or Wing It?
• Authentication and Identifiers
• Discovery
• Introduction Problem
• End User Support

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

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

110
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

111
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

112
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

113
eduPersonTargetedID

• Legacy attribute placeholder for the SAML 2.0
  persistent NameID format
• opaque
• pairwise (IdP/SP, could be shared by gt1 SP)
• original motivation was privacy, but strongest
  features are lack of reassignment and immunity to
  name changes
• ltsamlNameID
• Format"urnoasisnamestcSAML2.0nameid-format
  persistent"
• NameQualifier"https//testidp.example.com/idp/sh
  ibboleth"
• SPNameQualifier"https//testsp.example.com/shibb
  oleth"
• gtanystringthatcouldbeup256charslt/samlNameIDgt
• https//testidp.example.com/idp/shibboleth!https/
  /testsp.example.com/shibboleth!anystringthatcouldb
  eup256chars

114
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

115
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

116
Introduction 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.

117
Introduction 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.

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

119

• END

120
SAML Metadata

• Scope
• Terminology
• Migration Support
• Trust Management
• Identity Provider Metadata
• Service Provider Metadata

121
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

122
Scope

• Not in Scope
• Authorization policy
• Security policy
• Maybe in Scope
• Federation-asserted attributes about members
• Profiles for non-SAML protocol families

123
Other Relevancies

• WS-Federation metadata proposals
• WS-MetadataExchange
• XRI and XRDS (used by OpenID)
• DNSSEC, SRV records

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

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

126
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

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

128
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

129
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