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 2

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

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 4

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 5

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 6

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

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

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 9

10. Picking 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

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 11

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

13. Bootstrapping the SP (cont.) Provide metadata remotely from test IdP: $ 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"/> Supply metadata to parties of interest. (done for you) $ curl -k https://spN.example.com/Shibboleth.sso/Metadata 13

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 14

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

16. Trying your own IdP Adjust SessionInitiator and add metadata for your IdP to your SP: $ vi /etc/shibboleth/shibboleth2.xml Line 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

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 17

18. Use a Discovery Service Use a discovery service by changing the default SessionInitiator: $ vi /etc/shibboleth/shibboleth2.xml Line 105: <SessionInitiator type="Chaining" Location="/Login" isDefault="false" id="Intranet" relayState="cookie" Line 119: <SessionInitiator type="Chaining" Location="/DS" id="DS" relayState="cookie" isDefault="true" acsByIndex="false"> <SessionInitiator type="SAML2" defaultACSIndex="1" �/> <SessionInitiator type="Shib1" defaultACSIndex="5"/> <SessionInitiator type="SAMLDS" URL="https://ds.example.com/DS/WAYF"/> </SessionInitiator> 18

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

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

21. Session Creation Parameters https://spaces.internet2.edu/display/SHIB2/NativeSPSessionCreationParameters Key Parameters target (defaults to homeURL or "/") entityID (IdP to use, if known) Most parameters can come from three places, in order of precedence: query string parameter to handler a content setting (.htaccess or RequestMap) <SessionInitiator> element 21

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/content&entityID=https://idpN.example.com/idp/shibboleth 22

23. END 23

24. SP Basic Configuraton Summary of Files Structure of Master Configuration Changing Logging Levels Metadata .htaccess RequestMap Handlers 24

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 25

26. shibboleth2.xml Structure <OutOfProcess> / <InProcess> <UnixListener> / <TCPListener> <StorageService> <SessionCache> <ReplayCache> <ArtifactMap> <RequestMapper> <ApplicationDefaults> <SecurityPolicies> 26

27. shibboleth2.xml Structure <ApplicationDefaults> <Sessions> <Errors> <RelyingParty> (*) <MetadataProvider> <TrustEngine> <AttributeExtractor> <AttributeResolver> <AttributeFilter> <CredentialResolver> <ApplicationOverride> (*) 27

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 28

29. Logging: Tracing Messages Raise categories: $ vi shibd.logger Line 14: # tracing of SAML messages and security policies log4j.category.OpenSAML.MessageDecoder=DEBUG log4j.category.OpenSAML.MessageEncoder=DEBUG log4j.category.OpenSAML.SecurityPolicyRule=DEBUG To implement *.logger changes: $ touch shibboleth2.xml $ tail -f /var/log/shibboleth/shibd.log Test the SP again: https://spN.example.com/cgi-bin/test 29

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 30

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: <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

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: <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

33. Content Settings https://spaces.internet2.edu/display/SHIB2/NativeSPContentSettings Per-host, -directory, -file, -query Apache .htaccess Apache / IIS / other RequestMap Requires meticulous hostname "agreement"(we'll demo this later) Testing with: https://spN.example.com/cgi-bin/content 33

34. .htaccess Examples Requiring authentication: $ vi /var/www/cgi-bin/.htaccess AuthType shibboleth require shibboleth ShibRequestSetting requireSession 1 34

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

36. .htaccess Examples Bypassing SSO: $ vi /var/www/cgi-bin/.htaccess AuthType shibboleth require shibboleth ShibRequestSetting requireSession 1 ShibRequestSetting forceAuthn 1 36

37. RequestMap 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

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 38

39. RequestMap 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

40. RequestMap 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

41. Other Content Settings Requesting types of authentication Error handling pages Redirection-based error handling isPassive Supplying a specific IdP to use 41

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

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

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: <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID="https://testidp.example.com/idp/shibboleth"> 44

45. Some 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

46. Some 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

47. END 47

48. SP Attribute Handling Terminology Scoped Attributes Adding New Attribute Mappings REMOTE_USER and Identifiers Filtering Overview Source-Based Filtering Access Control 48

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

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

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

52. Dissecting an attribute rule <Attribute id="affiliation" aliases="affil" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> id the primary "id" to map into aliases optional alternate names to map into name SAML attribute name or NameID format to map from AttributeDecoder xsi:type decoder plugin to use (defaults to simple/string) caseSensitive how to compare values at runtime (defaults to true) 52

53. Adding mappings Add first and last name for both SAML 1 and SAML 2: $ vi /etc/shibboleth/attribute-map.xml <Attribute name="urn:mace:dir:attribute-def:sn" id="sn"/> <Attribute name="urn:mace:dir:attribute-def:givenName" id="givenName"/> <Attribute name="urn:oid:2.5.4.4" id="sn"/> <Attribute name="urn:oid:2.5.4.42" id="givenName"/> Takes effect immediately but NOT for any existing sessions. 53

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

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

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

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

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: <afp:AttributeRule attributeID="sn"> <afp:PermitValueRule xsi:type="AttributeIssuerString" value="https://idpN.example.com/idp/shibboleth"/> </afp:AttributeRule> 58

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 59

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 60

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(1|2)@example.com$ 61

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 (<AND>,<OR>,<NOT>). 62

63. XML 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

64. END 64

65. Session Initiators / Discovery Concepts Chains and protocol precedence Lazy sessions Discovery services Internal discovery mechanisms 65

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 66

67. Simplest Case Single IdP, single protocol, no discovery: <SessionInitiator type="SAML2" id="simple" isDefault="true" Location="/Login" entityID="https://testidp.example.com/idp/shibboleth" relayState="cookie" defaultACSIndex="1" template="bindingTemplate.html" /> Resembles the typical approach used in 1.3 SP but omits hardcoding the IdP's location. 67

68. Intranet Case Single IdP, multiple protocols, no discovery: <SessionInitiator type="Chaining" Location="/Login" id="Intranet" isDefault="true" relayState="cookie" entityID=" https://testidp.example.com/idp/shibboleth"> <SessionInitiator 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

69. Favoring Legacy Protocol Switch order of chain: $ vi /etc/shibboleth/shibboleth2.xml Line 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

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

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 71

72. DS Case Multiple protocols, discovery via DS: <SessionInitiator type="Chaining" Location="/DS" id="DS" isDefault="true" relayState="cookie"> <SessionInitiator type="SAML2" defaultACSIndex="1" acsByIndex="false" template="bindingTemplate.html"/> <SessionInitiator type="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

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 73

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

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

76. END 76

77. SP Advanced Integration Error Handling Logout 77

78. Error Handling Approaches https://spaces.internet2.edu/display/SHIB2/NativeSPErrors Default is to output customizable templates divided into a couple of types of errors. Templates written in HTML plus simple markup allowing information to be plugged in. PLEASE customize these pages. Optionally can redirect to a script on errors with parameters identifying the error. Major use case: passive SSO failure. 78

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

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

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

82. Application Notification https://spaces.internet2.edu/display/SHIB2/NativeSPNotify Applications can be notified when logout occurs by installing scripts to receive redirects or loopback XML messages. Notifications allow applications to clean up their state before the SP cleans up its own. 82

83. END 83

84. SP Virtualization Terminology Adding a second vhost-based application Clustering HTTP virtualization 84

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 85

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

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: <RequestMap applicationId="default"> <Host applicationId="alt"/> Line 243: <ApplicationOverride id="alt" entityID="https://altspN.example.com/shibboleth"/> </ApplicationDefaults> 87

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

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

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/NativeSPISAPI 90

91. END 91

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

93. Relying Party Settings https://spaces.internet2.edu/display/SHIB2/NativeSPRelyingParty Most settings are security- or connectivity-related: signing and encryption rules, algorithms selecting among multiple keys or certificates authentication types and connection timeouts for back-channel communications to IdPs rules for signing or encryption imposed on messages from IdPs 93

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

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: <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

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

97. END 97

98. Campus SSO Support OSU Experiences Pros Cons Strategies and Issues 98

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 99

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

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 101

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 102

103. Attributes, Attributes, Attributes Precise definitions Local semantics Conventions for header names Influence developer practices 103

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 104

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

106. END 106

107. Federating Applications Definitions Policy or Wing It? Authentication and Identifiers Discovery Introduction Problem End User Support 107

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

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

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 110

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 111

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 112

113. eduPersonTargetedID Legacy attribute placeholder for the SAML 2.0 persistent NameID format: opaque pairwise (IdP/SP, could be shared by >1 SP) original motivation was privacy, but strongest features are lack of reassignment and immunity to name changes <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://testidp.example.com/idp/shibboleth" SPNameQualifier="https://testsp.example.com/shibboleth" >anystringthatcouldbeup256chars</saml:NameID> https://testidp.example.com/idp/shibboleth!https://testsp.example.com/shibboleth!anystringthatcouldbeup256chars 113

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 114

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 115

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

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

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

119. END 119

120. SAML Metadata Scope Terminology Migration Support Trust Management Identity Provider Metadata Service Provider Metadata 120

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 121

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

123. Other Relevancies WS-Federation metadata proposals WS-MetadataExchange XRI and XRDS (used by OpenID) DNSSEC, SRV records 123

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

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

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 126

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

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 128

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 129