Shibboleth Advanced Operational Issues and Recommendations or Tomcat Ate My Brain Scott Cantor cantor.2@osu.edu Copyright Scott Cantor 2004. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

Identity Provider Considerations Apache/Tomcat Basics Deployment/Configuration Strategy Load Balancing Performance User Authentication Attribute Authority Extensibility 4/25/2019 2

Apache/Tomcat Basics Why do we need Apache? Tomcat supports SSL client authentication, but not without validation Why is Apache 2.0 a problem? Client authentication cannot be applied to a subset of the tree (patch pending) What is JK? Standard Apache/Tomcat protocol called AJP 1.3 Newest implementation available in mod_jk2 + Coyote (somewhat harder to configure than older versions) 4/25/2019 3

mod_jk2 Various binaries available from http://www.apache.org/dist/jakarta/tomcat-connectors/jk2/binaries/ Configuration of module done in /usr/local/apache/conf/workers2.properties Key settings: Port for Tomcat Coyote Connector URL trees to map into Tomcat 4/25/2019 4

Coyote Generalized architecture supporting multiple communication channels, can be used like old TCP-based connector Configured mostly in /usr/local/tomcat/conf/jk2.properties Key Settings request.tomcatAuthentication = false 4/25/2019 5

Common Pitfalls Apache request pool MUST be <= Tomcat connector maxThreads or you WILL get Server Errors. Enabling SSL client authentication to AA <Location "/shibboleth/AA"> SSLVerifyClient require SSLOptions +ExportCertData +StdEnvVars </Location> SSLCACertificateFile conf/inqueue-ca-bundle.crt Apache 2.0: Run the AA in its own vhost Use mod_ssl's "engine" log to help diagnose SSL errors 4/25/2019 6

Deployment/Configuration Strategies Default configuration uses relative paths for origin.xml, resolver.xml, ARP files, metadata Relative paths are resolved from within the shibboleth.war "virtual file system" By default, Tomcat expands warfiles when it deploys them, seducing you into editing files in the expanded tree. Resist its siren call! 4/25/2019 7

Deployment/Configuration Strategies A modest proposal: Unpack tarball into a permanent location on disk Modify webAppConfig/origin.xml and src/conf/origin.xml to reference other files and directories using absolute file:/// URLs Maintain configuration files, ARPs, etc. in the permanent location Edit /usr/local/tomcat/conf/server.xml, search for unpackWARs, and set to false (foul beast!) To install, run ant, copy endorsed jars, copy warfile to /usr/local/tomcat/webapps, start tomcat To change settings, edit files in permanent location and restart tomcat 4/25/2019 8

Load Balancing Primary consideration when load balancing is shared state between Authentication Authority (HS) and Attribute Authority. For opaque NameIdentifier formats (like Shibboleth handles), the AA must recover the principal name. The CryptoHandleGenerator <NameMapping> type enables this in a stateless manner. 4/25/2019 9

Load Balancing 1.2 SPs can query multiple Attribute Authority endpoints, but timeouts make this relatively impractical. Redirects to the Authentication Authority must be to a single endpoint. Generally, IdP should not expose load balancing and use an invisible mechanism. 4/25/2019 10

Performance As recounted in previous sessions, IdP overhead is driven by authentication overhead and signing overhead Highly CPU bound Essential to limit number of active requests to Authn Authority based on throughput, number of CPUs to prevent thrashing 4/25/2019 11

Performance Apache xml-security 1.1 is ~3 times faster Approximately 15 or so threads per CPU is probably a starting point, but needs study Tunable via maxHSThreads attribute in root of configuration file 4/25/2019 12

User Authentication Currently lacks any direct support for user authentication, just a typical secured web application Variety of mechanisms can be used via Apache or Tomcat SSO is the responsibility of the authentication mechanism 4/25/2019 13

User Authentication Looking ahead: Need a clean interface to authentication providers JAAS may be an ideal candidate Need some additional flexibility to assign qualities to providers (passivity, session reuse, authentication context) 4/25/2019 14

Some Attribute Authority Extensibility Points NameMapper Translates between SAML NameIdentifier and principal name ARP Engine Attribute Resolver Data Connector Attribute Definition SAML Attribute Value Handler 4/25/2019 15

Service Provider Considerations Architecture Lazy Sessions Load Balancing / Web Farms Attribute Query Handling 4/25/2019 16

Service Provider Architecture INTERNAL EXTERNAL ARP <Requester> Web Resources Shibboleth Application(s) <RequestMap> providerId Service Provider(s) Unit of Access Control Unit of Session Management and Configuration 4/25/2019 17

How To: Protect Resources <RequestMap> Every incoming request is “decomposed” into [http(s)]://[hostname]:[port]/[path]/[path]/… Default implementation supports applying settings at the host, port, and path level: applicationId requireSession (Apache: ShibRequireSession) exportAssertion (Apache: ShibExportAssertion) <AccessControlProvider> (Apache: require) Pluggable component 4/25/2019 18

How To: Protect Resources <RequestMap> in shibboleth.xml: <RequestMap applicationId="default"> <Host scheme="https" name="www.example.com"> <Path name="~scantor" requireSession="true"/> </Host> </RequestMap> httpd.conf / .htaccess: <Directory /home/scantor/www> AuthType shibboleth ShibRequireSession On require shibboleth (or valid-user or user or…) </Directory> 4/25/2019 19

How To: Protect Resources Processing Model Incoming request must be filtered by module/filter <RequestMapProvider> parses request and returns settings, including applicationId If default, then <Applications> element settings apply. Otherwise, a combination of default <Applications> and specific <Application> settings apply. A providerId is ultimately associated with the request for the purposes of requesting attributes of the identity provider's AA. 4/25/2019 20

How To: Protect Resources Assertion Consumer Services (shireURL) Applications contain (among their resources) one or more shireURL virtual endpoints implemented by Shibboleth. SP's publish their shireURL values as <AssertionConsumerService> elements in metadata. (Why? For security/privacy when persistent user identifiers used or attributes are pushed.) Basic rule: the RequestMap also processes requests to the ASC, and must map the request to the proper applicationId 4/25/2019 21

How To: Protect Resources Assertion Consumer Services (shireURL) When first access is to SP and a session is required, redirect to WAYF/IdP must include "shire" parameter containing ASC endpoint. Three syntaxes supported for shireURL: /Shibboleth.shire https://www.example.com/Shibboleth.shire https:///Shibboleth.shire ASC MUST be SSL-protected, or many attacks become possible. 4/25/2019 22

How To: Lazy Sessions Defers decision to establish session to resource. Enables stacking of multiple authentication methods (with caveats and much user confusion) With Apache, minimal content settings still required (AuthType shibboleth, require shibboleth) Simple "API" (works from any language): Issue redirect to an Assertion Consumer Service with a "target" parameter containing the resource to come back to 4/25/2019 23

Load Balancing / Farms SPs have a high degree of flexibility with respect to handling redirects in both Apache and IIS All aspects of the redirect (protocol, hostname, port) can be configured using httpd.conf commands or (for IIS or eventually Java) shibboleth.xml 4/25/2019 24

Attribute Query Handling New with 1.2, SPs can tailor how they react to query failures: Ignore/Propagate Retry Interval Timeouts Expiration Strictness Rich combination of optional/required behavior and accuracy tolerance 4/25/2019 25

Auditing IdP and SP each support transaction/audit logs separate from error logs Track issuance of handles to principals, and creation of sessions against those handles for specific applications Simple cross-referencing of handles to identify attackers (though handles can be ugly) 4/25/2019 26

Metadata / Trust Fabric Provider IDs Metadata vs. Trust/Revocation Bilateral Agreements Federations 4/25/2019 27

Provider IDs Every Identity and Service Provider MUST have a unique name (within the set of interacting providers). URIs guarantee uniqueness Implementation has moved away from applying policy based on partial name matching, and toward using metadata to aggregate providers as necessary 4/25/2019 28

Metadata Operational details that define the providers, the protocol endpoints, support for particular features Also used to identify (indirectly) the names of public keys used by providers to do particular things Implementation of abstract metadata API fully pluggable (LDAP, etc.) Future SAML 2.0 metadata: Allows key identification by value Supports metadata for a wider set of SAML features Allows Attribute Authorities to publish support for attributes Improves interoperability 4/25/2019 29

Names Endpoints Keys 4/25/2019 30 <SiteGroup Name="urn:mace:inqueue" xmlns="urn:mace:shibboleth:1.0"> <OriginSite Name="urn:mace:inqueue:example.edu"> <Alias>Example State University</Alias> <HandleService Location="https://wayf.internet2.edu/shibboleth-1.2/HS" Name="wayf.internet2.edu"/> <AttributeAuthority Location="https://wayf.internet2.edu/shibboleth-1.2/AA" Name="wayf.internet2.edu"/> <Domain>example.edu</Domain> </OriginSite> <DestinationSite Name="urn:mace:inqueue:example.edu"> <AssertionConsumerServiceURL Location="https://wayf.internet2.edu/Shibboleth.shire"/> <AttributeRequester Name="CN=wayf.internet2.edu, OU=TSG, O=University Corporation for Advanced Internet Development, L=Ann Arbor, ST=Michigan, C=US"/> </DestinationSite> </SiteGroup> 4/25/2019 30

Trust / Revocation MACEochists believe in separation of key identification from key validation Additional layer required to map from key names in metadata to certificates and/or CAs to validate a key binding In theory, replaceable by non-Shibboleth services provided by OS or other middleware Revocation supported in a basic kind of way 4/25/2019 31

For a key named localhost, use the embedded certificate For an identity provider in InQueue SiteGroup or the OSU IdP, use a pair of CAs <Trust xmlns="urn:mace:shibboleth:trust:1.0" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <KeyAuthority VerifyDepth="0"> <ds:KeyName>CN=localhost, O=Shibboleth Project, C=US</ds:KeyName> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>BASE64BLOB </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </KeyAuthority> <KeyAuthority VerifyDepth="5"> <ds:KeyName>urn:mace:inqueue</ds:KeyName> <ds:KeyName>urn:mace:incommon:osu.edu</ds:KeyName> <!-- Verisign/RSA Secure Server CA --> <!-- InCommon CA --> </Trust> 4/25/2019 32