Shibboleth 2.0 InstallFest Service Provider Material May 2008 Ann Arbor, MI
SP Overview and Installation <ul><li>Bearings and Terminology </li></ul><ul><li>Installation and Directory Structure </li>...
System Environment <ul><li>CentOS (Red Hat) 5 VM, ssh, &quot;password&quot; </li></ul><ul><li>Apache 2.2, running on stand...
Terminology <ul><li>Service Provider </li></ul><ul><ul><li>SAML-enabling middleware for web applications </li></ul></ul><u...
Installation <ul><li>RPM-based: </li></ul><ul><ul><li>$ rpm –ivh /opt/installfest/RPMS/*.rpm </li></ul></ul><ul><li>Done b...
Sanity Checks <ul><li>Start processes: </li></ul><ul><ul><li>$ /etc/init.d/shibd start </li></ul></ul><ul><ul><li>$ /etc/i...
Binaries <ul><li>/usr/sbin/shibd </li></ul><ul><li>/usr/bin/resolvertest </li></ul><ul><li>/usr/bin/mdquery </li></ul><ul>...
Supporting Files <ul><li>/etc/shibboleth </li></ul><ul><ul><li>master and supporting configuration files </li></ul></ul><u...
Key/Certificate Generation <ul><li>/etc/shibboleth/keygen.sh </li></ul><ul><li>Runs automatically during installation on m...
Picking an entityID <ul><li>How NOT to do it (but we’re doing it anyway): </li></ul><ul><ul><li>https://sp N .example.com/...
Bootstrapping the SP <ul><li>Goals: </li></ul><ul><ul><li>working SP against a single IdP </li></ul></ul><ul><ul><li>enabl...
Bootstrapping the SP (cont.) <ul><li>Relax some requirements and set your entityID and the IdP’s entityID. </li></ul><ul><...
Bootstrapping the SP (cont.) <ul><li>Provide metadata remotely from test IdP: </li></ul><ul><ul><li>$ vi /etc/shibboleth/s...
Testing the SP <ul><li>Try it with a browser: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/test </li></ul></ul>...
Logging Out <ul><li>To logout locally from the SP and kill your session: </li></ul><ul><ul><li>https://sp N .example.com/S...
Trying your own IdP <ul><li>Adjust SessionInitiator and add metadata for your IdP to your SP: </li></ul><ul><ul><li>$ vi /...
Testing <ul><li>Restart Tomcat (and the IdP) </li></ul><ul><ul><li>$ /etc/init.d/tomcat stop </li></ul></ul><ul><ul><li>$ ...
Use a Discovery Service <ul><li>Use a discovery service by changing the default SessionInitiator: </li></ul><ul><ul><li>$ ...
Lazy Sessions <ul><li>The mode of operation so far prevents an application from running without a login. </li></ul><ul><li...
Using Lazy Sessions <ul><li>In place of an API to &quot;doLogin&quot;, the SP uses redirects: </li></ul><ul><ul><li>https:...
Session Creation Parameters <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPSessionCreationParameters </li></ul...
Lazy Session Example <ul><li>Access unprotected script: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/content </...
<ul><li>END </li></ul>
SP Basic Configuraton <ul><li>Summary of Files </li></ul><ul><li>Structure of Master Configuration </li></ul><ul><li>Chang...
Configuration Files /etc/shibboleth <ul><li>shibboleth2.xml – master </li></ul><ul><li>apache*.config – Apache module load...
shibboleth2.xml Structure <ul><li><OutOfProcess> / <InProcess> </li></ul><ul><li><UnixListener> / <TCPListener> </li></ul>...
shibboleth2.xml Structure <ul><li><ApplicationDefaults> </li></ul><ul><ul><li><Sessions> </li></ul></ul><ul><ul><li><Error...
Logging <ul><li>Logging controlled independently between Apache and shibd (or globally to a syslog) </li></ul><ul><li>Tran...
Logging: Tracing Messages <ul><li>Raise categories: </li></ul><ul><ul><li>$ vi shibd.logger </li></ul></ul><ul><ul><li>Lin...
SP Metadata Features <ul><li>Four primary methods built-in: </li></ul><ul><ul><li>Local file (you manage it) </li></ul></u...
Signature Verification <ul><li>The test IdP's metadata is signed. Up until now, you loaded it without checking. </li></ul>...
Signature Verification <ul><li>Now preinstall the right signing key: </li></ul><ul><ul><li>$ cd /etc/shibboleth </li></ul>...
Content Settings <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPContentSettings </li></ul><ul><li>Per-host, -d...
.htaccess Examples <ul><li>Requiring authentication: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul>...
.htaccess Examples <ul><li>Auto-redirecting to SSL: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><...
.htaccess Examples <ul><li>Bypassing SSO: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><ul><ul><li...
RequestMap Examples <ul><li>Make sure .htaccess is in its original state. </li></ul><ul><li>Requiring authentication: </li...
RequestMap Fragility <ul><li>By default, Apache &quot;trusts&quot; the client about what the requested hostname is and rep...
RequestMap Examples <ul><li>Auto-redirecting to SSL: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul>...
RequestMap Examples <ul><li>Bypassing SSO: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><...
Other Content Settings <ul><li>Requesting types of authentication </li></ul><ul><li>Error handling pages </li></ul><ul><li...
SP Handlers <ul><li>&quot;Virtual&quot; applications inside the SP with access to its APIs: </li></ul><ul><ul><li>SessionI...
SP Handlers <ul><li>The URL of a handler is the handlerURL + the Location of the handler. </li></ul><ul><ul><li>e.g. for a...
Some Handler Options <ul><li>SessionInitiator and LogoutInitiators are the most &quot;tweakable&quot;. Some minor examples...
Some Handler Options <ul><li>Switch to Artifact binding for response: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibbolet...
Some Handler Options <ul><li>Switch from SAML 2 Redirect to POST: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.x...
<ul><li>END </li></ul>
SP Attribute Handling <ul><li>Terminology </li></ul><ul><li>Scoped Attributes </li></ul><ul><li>Adding New Attribute Mappi...
SP Attribute Terminology <ul><li>Push </li></ul><ul><ul><li>delivering attributes with SSO assertion </li></ul></ul><ul><l...
Scoped Attributes <ul><li>Common term across I2 middleware for attributes that consist of a relation between a value and a...
Attribute Mappings <ul><li>SAML attributes from any source are &quot;extracted&quot; using the configuration rules in attr...
Dissecting an attribute rule <ul><li><Attribute id=&quot;affiliation&quot; aliases=&quot;affil&quot; </li></ul><ul><li>nam...
Adding mappings <ul><li>Add first and last name for both SAML 1 and SAML 2: </li></ul><ul><ul><li>$ vi /etc/shibboleth/att...
REMOTE_USER <ul><li>Special single-valued variable that all web applications should support for container-managed authenti...
Changing REMOTE_USER <ul><li>Put the &quot;sn&quot; attribute into REMOTE_USER: </li></ul><ul><ul><li>$ vi /etc/shibboleth...
Attribute Filtering <ul><li>Answers the &quot;who can say what&quot; question on behalf of an application. </li></ul><ul><...
Default Policy <ul><li>Shared rule for legal affiliation values </li></ul><ul><li>Shared rule for scoped attributes </li><...
Add a Source-Based Rule <ul><li>Add a rule to limit acceptance of &quot;sn&quot; to a single IdP: </li></ul><ul><ul><li>$ ...
Access Control <ul><li>Not formally part of the SP, but cleanly integrated with it via an AccessControl API built into the...
.htaccess Access Control <ul><li>Special rules: </li></ul><ul><ul><li>shibboleth (no authz) </li></ul></ul><ul><ul><li>val...
.htaccess Example <ul><li>Require an entitlement or specific users: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess ...
XML Access Control <ul><li>Portable across servers, mainly an example of what's possible; competing with XACML is not a go...
XML Example <ul><li>Require an entitlement or specific users: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml <...
<ul><li>END </li></ul>
Session Initiators / Discovery <ul><li>Concepts </li></ul><ul><li>Chains and protocol precedence </li></ul><ul><li>Lazy se...
Session Initiators / Discovery Concepts <ul><li>Session Initiator </li></ul><ul><ul><li>handler that creates a SSO request...
Simplest Case <ul><li>Single IdP, single protocol, no discovery: </li></ul><ul><ul><li><SessionInitiator </li></ul></ul><u...
Intranet Case <ul><li>Single IdP, multiple protocols, no discovery: </li></ul><ul><ul><li><SessionInitiator type=&quot;Cha...
Favoring Legacy Protocol <ul><li>Switch order of chain: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></...
Discovery <ul><li>Protocol SessionInitiators work when the IdP is known. </li></ul><ul><li>For consistency, discovery is i...
Typical Discovery Methods <ul><li>External Options </li></ul><ul><ul><li>older WAYF model, specific to Shibboleth/SAML1, S...
DS Case <ul><li>Multiple protocols, discovery via DS: </li></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Lo...
Problems with External Discovery <ul><li>Loss of control, UI fidelity </li></ul><ul><li>Impact of errors </li></ul><ul><li...
Advanced SessionInitiators <ul><li>Form SessionInitiator </li></ul><ul><ul><li>Crude DS relying on HTML form template, NOT...
Advanced Example <ul><li>Use a form to prompt for the entityID, or a domain name or email address that is input to a conve...
<ul><li>END </li></ul>
SP Advanced Integration <ul><li>Error Handling </li></ul><ul><li>Logout </li></ul>
Error Handling Approaches <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPErrors </li></ul><ul><li>Default is t...
Logout <ul><li>Two types of sign-out operations: local and global. </li></ul><ul><li>Local logout affects only the SP (and...
IdP-initiated Logout <ul><li>Logout protocols that start at the IdP, such as SAML's, are implemented by SingleLogoutServic...
SP-initiated Logout <ul><li>Relies on a chain of handlers called LogoutInitiators. </li></ul><ul><li>Each handler understa...
Application Notification <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPNotify </li></ul><ul><li>Applications ...
<ul><li>END </li></ul>
SP Virtualization <ul><li>Terminology </li></ul><ul><li>Adding a second vhost-based application </li></ul><ul><li>Clusteri...
Terminology <ul><li>Service Provider (physical) </li></ul><ul><ul><li>an installation of the software on a server </li></u...
Virtualization Concepts <ul><li>A single physical SP can host any number of logical SPs. (virtual hosting) </li></ul><ul><...
Adding an Application <ul><li>Goal: add a second application with its own entityID living on its own virtual host. </li></...
Clustering <ul><li>Configure multiple physical installations to share an entityID, and possibly credentials. </li></ul><ul...
HTTP Virtualization <ul><li>Broadly, it's when the physical connection into a server has a different scheme, hostname, or ...
HTTP Virtualization <ul><li>The SP relies on the web server to be correctly configured. </li></ul><ul><ul><li>Apache virtu...
<ul><li>END </li></ul>
SP Relying Party Configuration <ul><li>Philosophically, goal is to reduce or eliminate IdP-specific settings: </li></ul><u...
Relying Party Settings <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPRelyingParty </li></ul><ul><li>Most sett...
Relying Party Selection <ul><li>API to acquire settings is metadata-based and not as flexible as it should be </li></ul><u...
Credential Selection Example <ul><li>Most common use case today. </li></ul><ul><li>With 2.0, credentials can be annotated ...
Complications <ul><li>Settings can only be chosen based on the IdP once the IdP is known. </li></ul><ul><li>Sometimes sett...
<ul><li>END </li></ul>
Campus SSO Support <ul><li>OSU Experiences </li></ul><ul><li>Pros </li></ul><ul><li>Cons </li></ul><ul><li>Strategies and ...
OSU Deployment <ul><li>Dates to 2004, accelerated deployment during 2005. </li></ul><ul><li>Migration from legacy software...
Pros <ul><li>Feature-rich without being fragile </li></ul><ul><li>Unified internal/external solution </li></ul><ul><li>Clu...
Cons <ul><li>Certificates and XML </li></ul><ul><li>Lack of web server expertise </li></ul><ul><li>Enforcing entityID sani...
Local Documentation <ul><li>Put in a local context and set expectations </li></ul><ul><li>Pointers to support resources, p...
Attributes, Attributes, Attributes <ul><li>Precise definitions </li></ul><ul><li>Local semantics </li></ul><ul><li>Convent...
Process <ul><li>Certificate strategy: take advantage of 2.0 keypair generation </li></ul><ul><li>SP registration: manual o...
Federation Implications <ul><li>Few local services may be interested in federating, and few of those may be ready. </li></...
<ul><li>END </li></ul>
Federating Applications <ul><li>Definitions </li></ul><ul><li>Policy or Wing It? </li></ul><ul><li>Authentication and Iden...
Definitions <ul><li>Federation of an application </li></ul><ul><ul><li>Accepting identity attributes from multiple, distin...
Policy vs. Expediency <ul><li>Address everything up front contractually or rely on remediation strategies through existing...
Externalizing Authentication <ul><li>Most visible, well understood part </li></ul><ul><li>Analagous to making SSO work loc...
Identifiers <ul><li>Must determine application requirements for different kinds of identifiers. </li></ul><ul><li>Assumpti...
Common Identifiers <ul><li>local userid/netid </li></ul><ul><ul><li>usually readable, persistent but not permanent, often ...
eduPersonTargetedID <ul><li>Legacy attribute placeholder for the SAML 2.0 persistent NameID format: </li></ul><ul><ul><li>...
eduPersonTargetedID <ul><li>Minimally supported so far: </li></ul><ul><ul><li>not easily stored in LDAP </li></ul></ul><ul...
Discovery <ul><li>Two kinds of applications: </li></ul><ul><ul><li>relatively balanced audience across IdPs </li></ul></ul...
Introduction Problem <ul><li>More pronounced with federation, but can arise with SSO alone. </li></ul><ul><li>Traditional ...
Introduction Problem <ul><li>Basic use case: </li></ul><ul><ul><li>I want to add person X to a group or give them to acces...
End User Support <ul><li>Supporting a federated application from the IdP side is a dead end (e.g. OpenID). </li></ul><ul><...
<ul><li>END </li></ul>
SAML Metadata <ul><li>Scope </li></ul><ul><li>Terminology </li></ul><ul><li>Migration Support </li></ul><ul><li>Trust Mana...
Scope <ul><li>Entities in hierarchical groups </li></ul><ul><li>Peer roles and protocol support </li></ul><ul><li>Profile ...
Scope <ul><li>Not in Scope: </li></ul><ul><ul><li>Authorization policy </li></ul></ul><ul><ul><li>Security policy </li></u...
Other Relevancies <ul><li>WS-Federation metadata proposals </li></ul><ul><li>WS-MetadataExchange </li></ul><ul><li>XRI and...
Terminology <ul><li>EntityDescriptor </li></ul><ul><ul><li>A distinct SAML-supporting system, can be collected into Entiti...
Supporting Migration <ul><li>Metadata use backported to SAML 1.1 by Shibboleth project, standardized at OASIS. </li></ul><...
Trust Management <ul><li>Agreement </li></ul><ul><ul><li>Vehicle for communicating who can be trusted and how to establish...
Trust Management <ul><li>Shibboleth Implementation and Goals </li></ul><ul><ul><li>Produce a well-documented and understan...
Identity Provider Metadata <ul><li>Typically include IdP and AA roles, reflecting attribute query use in Shibboleth </li><...
Service Provider Metadata <ul><li>Role representing notion of a SAML-enabled web site supporting SSO profiles </li></ul><u...
Upcoming SlideShare
Loading in …5
×

Shibboleth 2.0 SP slides - Installfest

9,679 views

Published on

Shibboleth 2.0 Installfest, 1-2 July, Birmingham.

Published in: Technology, Health & Medicine
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,679
On SlideShare
0
From Embeds
0
Number of Embeds
39
Actions
Shares
0
Downloads
150
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Shibboleth 2.0 SP slides - Installfest

  1. 1. Shibboleth 2.0 InstallFest Service Provider Material May 2008 Ann Arbor, MI
  2. 2. SP Overview and Installation <ul><li>Bearings and Terminology </li></ul><ul><li>Installation and Directory Structure </li></ul><ul><li>Generating Key and Certificate </li></ul><ul><li>Picking an entityID </li></ul><ul><li>Initial Configuration </li></ul><ul><li>Testing </li></ul>
  3. 3. System Environment <ul><li>CentOS (Red Hat) 5 VM, ssh, &quot;password&quot; </li></ul><ul><li>Apache 2.2, running on standard ports </li></ul><ul><li>Bogus SSL certificates </li></ul><ul><li>AuthConfig added to /cgi-bin for .htaccess </li></ul><ul><li>Hostnames: </li></ul><ul><ul><li>sp N .example.com </li></ul></ul><ul><ul><li>altsp N .example.com (later) </li></ul></ul>
  4. 4. Terminology <ul><li>Service Provider </li></ul><ul><ul><li>SAML-enabling middleware for web applications </li></ul></ul><ul><li>shibd </li></ul><ul><ul><li>SP service/daemon for maintaining state </li></ul></ul><ul><li>Session </li></ul><ul><ul><li>Security context and cached data for a logged-in user </li></ul></ul><ul><li>SessionInitiator </li></ul><ul><ul><li>Part of SP that generates SSO requests </li></ul></ul><ul><li>MetadataProvider </li></ul><ul><ul><li>Provides secure information about IdPs at runtime </li></ul></ul><ul><li>CredentialResolver </li></ul><ul><ul><li>Interface from SP to its keys and certificates </li></ul></ul>
  5. 5. Installation <ul><li>RPM-based: </li></ul><ul><ul><li>$ rpm –ivh /opt/installfest/RPMS/*.rpm </li></ul></ul><ul><li>Done by RPM after installation: </li></ul><ul><ul><li>cp /etc/shibboleth/apache22.conf ig/etc/httpd/conf.d/shib.conf </li></ul></ul><ul><ul><li>cp /etc/shibboleth/shibd-redhat /etc/init.d/shibd </li></ul></ul>
  6. 6. Sanity Checks <ul><li>Start processes: </li></ul><ul><ul><li>$ /etc/init.d/shibd start </li></ul></ul><ul><ul><li>$ /etc/init.d/httpd start </li></ul></ul><ul><li>Check status locally from shell: </li></ul><ul><ul><li>$ curl -k https://localhost/Shibboleth.sso/Status </li></ul></ul><ul><li>Access session handler from browser: </li></ul><ul><ul><li>https://sp N .example.com/Shibboleth.sso/Session </li></ul></ul><ul><li>Intentionally trigger an error from browser: </li></ul><ul><ul><li>https://sp N .example.com/Shibboleth.sso/Foo </li></ul></ul>
  7. 7. Binaries <ul><li>/usr/sbin/shibd </li></ul><ul><li>/usr/bin/resolvertest </li></ul><ul><li>/usr/bin/mdquery </li></ul><ul><li>/usr/lib/shibboleth/*.so </li></ul><ul><ul><li>Apache/etc. modules, SP extensions </li></ul></ul>
  8. 8. Supporting Files <ul><li>/etc/shibboleth </li></ul><ul><ul><li>master and supporting configuration files </li></ul></ul><ul><ul><li>locally maintained metadata files </li></ul></ul><ul><ul><li>HTML templates </li></ul></ul><ul><ul><li>logging configuration files </li></ul></ul><ul><ul><li>credentials </li></ul></ul><ul><li>/var/run/shibboleth </li></ul><ul><ul><li>UNIX socket </li></ul></ul><ul><ul><li>remote metadata backups </li></ul></ul><ul><li>/var/log/shibboleth </li></ul><ul><ul><li>shibd and transaction logs </li></ul></ul><ul><li>/var/log/httpd </li></ul><ul><ul><li>native log (after permission change) </li></ul></ul>
  9. 9. Key/Certificate Generation <ul><li>/etc/shibboleth/keygen.sh </li></ul><ul><li>Runs automatically during installation on most platforms. </li></ul><ul><li>For this event, copy over a pre-generated set for your assigned SP number: </li></ul><ul><ul><li>$ cp /opt/installfest/sp N /sp.key /etc/shibboleth/sp-key.pem </li></ul></ul><ul><ul><li>$ cp /opt/installfest/sp N /sp.crt /etc/shibboleth/sp-cert.pem </li></ul></ul>
  10. 10. Picking an entityID <ul><li>How NOT to do it (but we’re doing it anyway): </li></ul><ul><ul><li>https://sp N .example.com/shibboleth </li></ul></ul><ul><li>Why not? </li></ul><ul><ul><li>Names should be unique, locally scoped, logical, representative, unchanging. </li></ul></ul><ul><li>Where are they used? </li></ul><ul><ul><li>On the wire, local configuration, metadata </li></ul></ul><ul><ul><li>IdP log files, configuration, filtering policies </li></ul></ul>
  11. 11. Bootstrapping the SP <ul><li>Goals: </li></ul><ul><ul><li>working SP against a single IdP </li></ul></ul><ul><ul><li>enable debugging of session attributes </li></ul></ul><ul><ul><li>avoid clock complaints </li></ul></ul><ul><li>Give Apache the hostname. </li></ul><ul><ul><li>$ vi /etc/httpd/conf/httpd.conf </li></ul></ul><ul><ul><li>Line 265: </li></ul></ul><ul><ul><ul><li>ServerName sp N .example.com </li></ul></ul></ul>
  12. 12. Bootstrapping the SP (cont.) <ul><li>Relax some requirements and set your entityID and the IdP’s entityID. </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 6 (Do NOT do this in production) : </li></ul></ul><ul><ul><li>logger=&quot;syslog.logger&quot; clockSkew=&quot;180000&quot; > </li></ul></ul><ul><ul><li>Line 77: </li></ul></ul><ul><ul><li><ApplicationDefaults id=&quot;default&quot; policyId=&quot;default&quot; entityID=&quot;https://sp N .example.com/shibboleth&quot; > </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;true&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; entityID=&quot;https://testidp.example.com/idp/shibboleth&quot; > </li></ul></ul><ul><ul><li>Line 184: </li></ul></ul><ul><ul><li><Handler type=&quot;Session&quot; Location=&quot;/Session&quot; showAttributeValues=&quot;true&quot; /> </li></ul></ul>
  13. 13. Bootstrapping the SP (cont.) <ul><li>Provide metadata remotely from test IdP: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 208: </li></ul></ul><ul><ul><li><MetadataProvider type=&quot;Chaining&quot;> </li></ul></ul><ul><ul><ul><li><MetadataProvider type=&quot;XML&quot; url=&quot;https://testidp.example.com/testidp-metadata.xml&quot; backingFilePath=&quot;testidp-metadata.xml&quot; reloadInterval=&quot;3600&quot;/> </li></ul></ul></ul><ul><li>Supply metadata to parties of interest. (done for you) </li></ul><ul><ul><li>$ curl -k https://sp N .example.com/Shibboleth.sso/Metadata </li></ul></ul>
  14. 14. Testing the SP <ul><li>Try it with a browser: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/test </li></ul></ul><ul><li>Dump your session: </li></ul><ul><ul><ul><li>https://sp N .example.com/Shibboleth.sso/Session </li></ul></ul></ul>
  15. 15. Logging Out <ul><li>To logout locally from the SP and kill your session: </li></ul><ul><ul><li>https://sp N .example.com/Shibboleth.sso/Logout </li></ul></ul><ul><li>Or just close the browser and start over. </li></ul>
  16. 16. Trying your own IdP <ul><li>Adjust SessionInitiator and add metadata for your IdP to your SP: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;true&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; entityID=&quot;https://idp N .example.com/idp/shibboleth&quot; > </li></ul></ul><ul><ul><li>Line 208: </li></ul></ul><ul><ul><li><MetadataProvider type=&quot;Chaining&quot;> </li></ul></ul><ul><ul><ul><li><MetadataProvider type=&quot;XML&quot; path=&quot;/opt/installfest/idp N /idp N -metadata.xml&quot;/> </li></ul></ul></ul><ul><li>Add metadata for your SP to your IdP: </li></ul><ul><ul><li>$ vi /opt/shibboleth-idp/conf/relying-party.xml </li></ul></ul><ul><ul><li><MetadataProvider id=&quot;ShibbolethMetadata&quot; xsi:type=&quot;ChainingMetadataProvider&quot; xmlns=&quot;urn:mace:shibboleth:2.0:metadata&quot;> </li></ul></ul><ul><ul><ul><li><MetadataProvider id=&quot;SP N &quot; xsi:type=&quot;FilesystemMetadataProvider&quot; xmlns=&quot;urn:mace:shibboleth:2.0:metadata&quot; </li></ul></ul></ul><ul><ul><ul><li>metadataFile=&quot;/opt/installfest/sp N /sp N -metadata.xml&quot;/> </li></ul></ul></ul>
  17. 17. Testing <ul><li>Restart Tomcat (and the IdP) </li></ul><ul><ul><li>$ /etc/init.d/tomcat stop </li></ul></ul><ul><ul><li>$ ps –ef | grep java </li></ul></ul><ul><ul><li>$ /etc/init.d/tomcat restart </li></ul></ul><ul><li>Try it with a browser: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/test </li></ul></ul><ul><li>Dump your session: </li></ul><ul><ul><ul><li>https://sp N .example.com/Shibboleth.sso/Session </li></ul></ul></ul>
  18. 18. Use a Discovery Service <ul><li>Use a discovery service by changing the default SessionInitiator: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;false&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; </li></ul></ul><ul><ul><li>Line 119: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/DS&quot; id=&quot;DS&quot; relayState=&quot;cookie&quot; isDefault=&quot;true&quot; acsByIndex=&quot;false&quot; > </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; …/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Shib1&quot; defaultACSIndex=&quot;5&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAMLDS&quot; URL=&quot;https://ds.example.com/DS/WAYF&quot; /> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul>
  19. 19. Lazy Sessions <ul><li>The mode of operation so far prevents an application from running without a login. </li></ul><ul><li>Two other very common cases: </li></ul><ul><ul><li>public and private access to the same resources </li></ul></ul><ul><ul><li>separation of application and SP session </li></ul></ul><ul><li>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. </li></ul>
  20. 20. Using Lazy Sessions <ul><li>In place of an API to &quot;doLogin&quot;, the SP uses redirects: </li></ul><ul><ul><li>https://testsp1.example.com/Shibboleth.sso/Login </li></ul></ul><ul><li>When you want a login to happen, redirect the browser to a SessionInitiator (/Login by convention) with any parameters you want to supply. </li></ul>
  21. 21. Session Creation Parameters <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPSessionCreationParameters </li></ul><ul><li>Key Parameters </li></ul><ul><ul><li>target (defaults to homeURL or &quot;/&quot;) </li></ul></ul><ul><ul><li>entityID (IdP to use, if known) </li></ul></ul><ul><li>Most parameters can come from three places, in order of precedence: </li></ul><ul><ul><li>query string parameter to handler </li></ul></ul><ul><ul><li>a content setting (.htaccess or RequestMap) </li></ul></ul><ul><ul><li><SessionInitiator> element </li></ul></ul>
  22. 22. Lazy Session Example <ul><li>Access unprotected script: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/content </li></ul></ul><ul><li>View source to see the Login links: </li></ul><ul><ul><li>/Shibboleth.sso/Login?target=/cgi-bin/content </li></ul></ul><ul><ul><li>/Shibboleth.sso/DS?target=/cgi-bin/content </li></ul></ul><ul><li>Copy it and add any other parameters to see the result: e.g. try supplying the IdP: </li></ul><ul><ul><li>/Shibboleth.sso/Login? target=/cgi-bin/content& entityID=https://idp N .example.com/idp/shibboleth </li></ul></ul>
  23. 23. <ul><li>END </li></ul>
  24. 24. SP Basic Configuraton <ul><li>Summary of Files </li></ul><ul><li>Structure of Master Configuration </li></ul><ul><li>Changing Logging Levels </li></ul><ul><li>Metadata </li></ul><ul><li>.htaccess </li></ul><ul><li>RequestMap </li></ul><ul><li>Handlers </li></ul>
  25. 25. Configuration Files /etc/shibboleth <ul><li>shibboleth2.xml – master </li></ul><ul><li>apache*.config – Apache module loading </li></ul><ul><li>attribute-map.xml – attribute handling </li></ul><ul><li>attribute-policy.xml – attribute filtering </li></ul><ul><li>*.logger – logging levels </li></ul><ul><li>*Error.html – error templates </li></ul><ul><li>localLogout.html – SP-only logout template </li></ul><ul><li>globalLogout.html – single logout template </li></ul>
  26. 26. shibboleth2.xml Structure <ul><li><OutOfProcess> / <InProcess> </li></ul><ul><li><UnixListener> / <TCPListener> </li></ul><ul><li><StorageService> </li></ul><ul><li><SessionCache> </li></ul><ul><li><ReplayCache> </li></ul><ul><li><ArtifactMap> </li></ul><ul><li><RequestMapper> </li></ul><ul><li><ApplicationDefaults> </li></ul><ul><li><SecurityPolicies> </li></ul>
  27. 27. shibboleth2.xml Structure <ul><li><ApplicationDefaults> </li></ul><ul><ul><li><Sessions> </li></ul></ul><ul><ul><li><Errors> </li></ul></ul><ul><ul><li><RelyingParty> (*) </li></ul></ul><ul><ul><li><MetadataProvider> </li></ul></ul><ul><ul><li><TrustEngine> </li></ul></ul><ul><ul><li><AttributeExtractor> </li></ul></ul><ul><ul><li><AttributeResolver> </li></ul></ul><ul><ul><li><AttributeFilter> </li></ul></ul><ul><ul><li><CredentialResolver> </li></ul></ul><ul><ul><li><ApplicationOverride> (*) </li></ul></ul>
  28. 28. Logging <ul><li>Logging controlled independently between Apache and shibd (or globally to a syslog) </li></ul><ul><li>Transaction log handled out of shibd as a separate stream </li></ul><ul><li>*.logger files contain predefined settings for output locations and a default logging level (INFO) along with useful categories to raise to DEBUG </li></ul>
  29. 29. Logging: Tracing Messages <ul><li>Raise categories: </li></ul><ul><ul><li>$ vi shibd.logger </li></ul></ul><ul><ul><li>Line 14: </li></ul></ul><ul><ul><li># tracing of SAML messages and security policies </li></ul></ul><ul><ul><li>log4j.category.OpenSAML.MessageDecoder=DEBUG </li></ul></ul><ul><ul><li>log4j.category.OpenSAML.MessageEncoder=DEBUG </li></ul></ul><ul><ul><li>log4j.category.OpenSAML.SecurityPolicyRule=DEBUG </li></ul></ul><ul><li>To implement *.logger changes: </li></ul><ul><ul><li>$ touch shibboleth2.xml </li></ul></ul><ul><ul><li>$ tail -f /var/log/shibboleth/shibd.log </li></ul></ul><ul><li>Test the SP again: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/test </li></ul></ul>
  30. 30. SP Metadata Features <ul><li>Four primary methods built-in: </li></ul><ul><ul><li>Local file (you manage it) </li></ul></ul><ul><ul><li>Remote file (periodic refresh, backed up for you) </li></ul></ul><ul><ul><li>Dynamic resolution of entityID </li></ul></ul><ul><ul><li>&quot;Null&quot; source that disables security </li></ul></ul><ul><li>Security comes from metadata filtering, either by you or the SP: </li></ul><ul><ul><li>Signature verification </li></ul></ul><ul><ul><li>White and blacklists </li></ul></ul>
  31. 31. Signature Verification <ul><li>The test IdP's metadata is signed. Up until now, you loaded it without checking. </li></ul><ul><li>First, &quot;break&quot; it: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 208: </li></ul></ul><ul><ul><li><MetadataProvider type=&quot;Chaining&quot;> </li></ul></ul><ul><ul><ul><li><MetadataProvider type=&quot;XML&quot; url=&quot;https://testidp.example.com/testidp-metadata.xml&quot; backingFilePath=&quot;testidp-metadata.xml&quot; reloadInterval=&quot;3600&quot;> </li></ul></ul></ul><ul><ul><ul><li><SignatureMetadataFilter certificate=&quot;sp-cert.pem&quot;/> </li></ul></ul></ul><ul><ul><ul><li></MetadataProvider> </li></ul></ul></ul>
  32. 32. Signature Verification <ul><li>Now preinstall the right signing key: </li></ul><ul><ul><li>$ cd /etc/shibboleth </li></ul></ul><ul><ul><li>$ wget https://testidp.example.com/idp.crt </li></ul></ul><ul><li>Then fix it: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 208: </li></ul></ul><ul><ul><li><MetadataProvider type=&quot;Chaining&quot;> </li></ul></ul><ul><ul><ul><li><MetadataProvider type=&quot;XML&quot; url=&quot;https://testidp.example.com/testidp-metadata.xml&quot; backingFilePath=&quot;testidp-metadata.xml&quot; reloadInterval=&quot;3600&quot;> </li></ul></ul></ul><ul><ul><ul><li><SignatureMetadataFilter certificate=&quot; idp.crt &quot;/> </li></ul></ul></ul><ul><ul><ul><li></MetadataProvider> </li></ul></ul></ul>
  33. 33. Content Settings <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPContentSettings </li></ul><ul><li>Per-host, -directory, -file, -query </li></ul><ul><li>Apache </li></ul><ul><ul><li>.htaccess </li></ul></ul><ul><li>Apache / IIS / other </li></ul><ul><ul><li>RequestMap </li></ul></ul><ul><ul><ul><li>Requires meticulous hostname &quot;agreement&quot; (we'll demo this later) </li></ul></ul></ul><ul><li>Testing with: </li></ul><ul><ul><li>https://sp N .example.com/cgi-bin/content </li></ul></ul>
  34. 34. .htaccess Examples <ul><li>Requiring authentication: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><ul><ul><li>AuthType shibboleth </li></ul></ul><ul><ul><li>require shibboleth </li></ul></ul><ul><ul><li>ShibRequestSetting requireSession 1 </li></ul></ul>
  35. 35. .htaccess Examples <ul><li>Auto-redirecting to SSL: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><ul><ul><li>AuthType shibboleth </li></ul></ul><ul><ul><li>require shibboleth </li></ul></ul><ul><ul><li>ShibRequestSetting requireSession 1 </li></ul></ul><ul><ul><li>ShibRequestSetting redirectToSSL 443 </li></ul></ul>
  36. 36. .htaccess Examples <ul><li>Bypassing SSO: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><ul><ul><li>AuthType shibboleth </li></ul></ul><ul><ul><li>require shibboleth </li></ul></ul><ul><ul><li>ShibRequestSetting requireSession 1 </li></ul></ul><ul><ul><li>ShibRequestSetting forceAuthn 1 </li></ul></ul>
  37. 37. RequestMap Examples <ul><li>Make sure .htaccess is in its original state. </li></ul><ul><li>Requiring authentication: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 62: </li></ul></ul><ul><ul><li><Host name=&quot; sp N .example.com &quot;> </li></ul></ul><ul><ul><li><Path name=&quot; cgi-bin &quot; authType=&quot;shibboleth&quot; </li></ul></ul><ul><ul><li>requireSession=&quot;true&quot;/> </li></ul></ul><ul><ul><li></Host> </li></ul></ul>
  38. 38. RequestMap Fragility <ul><li>By default, Apache &quot;trusts&quot; the client about what the requested hostname is and reports that value internally. </li></ul><ul><li>To illustrate, now that the &quot;content&quot; script is protected, try this URL: </li></ul><ul><ul><li>https://altsp N .example.com/cgi-bin/content </li></ul></ul><ul><li>How to fix? </li></ul><ul><ul><li>vi /etc/httpd/conf/httpd.conf </li></ul></ul><ul><ul><li>UseCanonicalName On </li></ul></ul>
  39. 39. RequestMap Examples <ul><li>Auto-redirecting to SSL: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 62: </li></ul></ul><ul><ul><li><Host name=&quot;sp N .example.com&quot;> </li></ul></ul><ul><ul><li><Path name=&quot;cgi-bin&quot; authType=&quot;shibboleth&quot; </li></ul></ul><ul><ul><li>requireSession=&quot;true&quot; redirectToSSL=&quot;443&quot; /> </li></ul></ul><ul><ul><li></Host> </li></ul></ul>
  40. 40. RequestMap Examples <ul><li>Bypassing SSO: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 62: </li></ul></ul><ul><ul><li><Host name=&quot;sp N .example.com&quot;> </li></ul></ul><ul><ul><li><Path name=&quot;cgi-bin&quot; authType=&quot;shibboleth&quot; </li></ul></ul><ul><ul><li>requireSession=&quot;true&quot; forceAuthn=&quot;true&quot; /> </li></ul></ul><ul><ul><li></Host> </li></ul></ul>
  41. 41. Other Content Settings <ul><li>Requesting types of authentication </li></ul><ul><li>Error handling pages </li></ul><ul><li>Redirection-based error handling </li></ul><ul><li>isPassive </li></ul><ul><li>Supplying a specific IdP to use </li></ul>
  42. 42. SP Handlers <ul><li>&quot;Virtual&quot; applications inside the SP with access to its APIs: </li></ul><ul><ul><li>SessionInitiator (requests) </li></ul></ul><ul><ul><li>AssertionConsumerService (incoming SSO) </li></ul></ul><ul><ul><li>LogoutInitiator (SP signout) </li></ul></ul><ul><ul><li>SingleLogoutService (incoming SLO) </li></ul></ul><ul><ul><li>ManageNameIDService (adv. SAML) </li></ul></ul><ul><ul><li>ArtifactResolutionService (adv. SAML) </li></ul></ul><ul><ul><li>Generic (diagnostics, other useful features) </li></ul></ul>
  43. 43. SP Handlers <ul><li>The URL of a handler is the handlerURL + the Location of the handler. </li></ul><ul><ul><li>e.g. for a virtual host testsp.example.com with handlerURL of &quot;/Shibboleth.sso&quot;, a handler with a Location of &quot;/Login&quot; will be https://testsp.example.com/Shibboleth.sso/Login </li></ul></ul><ul><li>Handlers aren’t always SSL-only, but usually should be (handlerSSL=&quot;true&quot;). </li></ul><ul><li>Most of your metadata consists of your entityID, your keys, and your handlers. </li></ul><ul><li>Handlers are never &quot;protected&quot; by the SP. </li></ul>
  44. 44. Some Handler Options <ul><li>SessionInitiator and LogoutInitiators are the most &quot;tweakable&quot;. Some minor examples: </li></ul><ul><li>Remove relayState to pass URLs by value. </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;true&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; entityID=&quot;https://testidp.example.com/idp/shibboleth&quot;> </li></ul></ul>
  45. 45. Some Handler Options <ul><li>Switch to Artifact binding for response: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;true&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; entityID=&quot;https://testidp.example.com/idp/shibboleth&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;2&quot; template=&quot;bindingTemplate.html&quot;/> </li></ul></ul>
  46. 46. Some Handler Options <ul><li>Switch from SAML 2 Redirect to POST: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; isDefault=&quot;true&quot; id=&quot;Intranet&quot; relayState=&quot;cookie&quot; entityID=&quot;https://testidp.example.com/idp/shibboleth&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; template=&quot;bindingTemplate.html&quot; </li></ul></ul><ul><ul><li>outgoingBindings=&quot;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST&quot; /> </li></ul></ul>
  47. 47. <ul><li>END </li></ul>
  48. 48. SP Attribute Handling <ul><li>Terminology </li></ul><ul><li>Scoped Attributes </li></ul><ul><li>Adding New Attribute Mappings </li></ul><ul><li>REMOTE_USER and Identifiers </li></ul><ul><li>Filtering Overview </li></ul><ul><li>Source-Based Filtering </li></ul><ul><li>Access Control </li></ul>
  49. 49. SP Attribute Terminology <ul><li>Push </li></ul><ul><ul><li>delivering attributes with SSO assertion </li></ul></ul><ul><li>Pull </li></ul><ul><ul><li>querying for attributes after SSO </li></ul></ul><ul><li>Extraction </li></ul><ul><ul><li>decoding SAML information into neutral data structures mapped to environment or header variables </li></ul></ul><ul><li>Filtering </li></ul><ul><ul><li>blocking invalid, unexpected, or unauthorized values based on application or community criteria </li></ul></ul><ul><li>Resolution </li></ul><ul><ul><li>resolving a SSO assertion into a set of additional attributes (e.g. queries) </li></ul></ul>
  50. 50. Scoped Attributes <ul><li>Common term across I2 middleware for attributes that consist of a relation between a value and a &quot;scope&quot;, usually an organizational domain or subdomain. </li></ul><ul><li>Makes simpler values globally usable or unique. </li></ul><ul><li>Lots of special treatment in Shibboleth to make them more useful and &quot;safe&quot;. </li></ul>
  51. 51. Attribute Mappings <ul><li>SAML attributes from any source are &quot;extracted&quot; using the configuration rules in attribute-map.xml </li></ul><ul><li>Each element is a rule for decoding a SAML attribute and assigning it a local &quot;id&quot; which becomes its mapped variable name. </li></ul><ul><li>Attributes can have > 1 &quot;id&quot; and multiple attributes can be mapped to the same &quot;id&quot;. </li></ul><ul><li>Decoders are attribute-independent but syntax-dependent. </li></ul>
  52. 52. Dissecting an attribute rule <ul><li><Attribute id=&quot;affiliation&quot; aliases=&quot;affil&quot; </li></ul><ul><li>name=&quot;urn:mace:dir:attribute-def:eduPersonScopedAffiliation&quot;> </li></ul><ul><li><AttributeDecoder xsi:type=&quot;ScopedAttributeDecoder&quot; </li></ul><ul><li>caseSensitive=&quot;false&quot;/> </li></ul><ul><li></Attribute> </li></ul><ul><ul><li>id </li></ul></ul><ul><ul><ul><li>the primary &quot;id&quot; to map into </li></ul></ul></ul><ul><ul><li>aliases </li></ul></ul><ul><ul><ul><li>optional alternate names to map into </li></ul></ul></ul><ul><ul><li>name </li></ul></ul><ul><ul><ul><li>SAML attribute name or NameID format to map from </li></ul></ul></ul><ul><ul><li>AttributeDecoder xsi:type </li></ul></ul><ul><ul><ul><li>decoder plugin to use (defaults to simple/string) </li></ul></ul></ul><ul><ul><li>caseSensitive </li></ul></ul><ul><ul><ul><li>how to compare values at runtime (defaults to true) </li></ul></ul></ul>
  53. 53. Adding mappings <ul><li>Add first and last name for both SAML 1 and SAML 2: </li></ul><ul><ul><li>$ vi /etc/shibboleth/attribute-map.xml </li></ul></ul><ul><ul><li><Attribute name=&quot;urn:mace:dir:attribute-def:sn&quot; id=&quot;sn&quot;/> </li></ul></ul><ul><ul><li><Attribute name=&quot;urn:mace:dir:attribute-def:givenName&quot; id=&quot;givenName&quot;/> </li></ul></ul><ul><ul><li><Attribute name=&quot;urn:oid:2.5.4.4&quot; id=&quot;sn&quot;/> </li></ul></ul><ul><ul><li><Attribute name=&quot;urn:oid:2.5.4.42&quot; id=&quot;givenName&quot;/> </li></ul></ul><ul><li>Takes effect immediately but NOT for any existing sessions. </li></ul>
  54. 54. REMOTE_USER <ul><li>Special single-valued variable that all web applications should support for container-managed authentication of a unique user. </li></ul><ul><li>Any attributes, once extracted/mapped, can be copied to REMOTE_USER. </li></ul><ul><li>Multiple attributes can be examined in order of preference, but only the first value will be used. </li></ul>
  55. 55. Changing REMOTE_USER <ul><li>Put the &quot;sn&quot; attribute into REMOTE_USER: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 80: </li></ul></ul><ul><ul><li>REMOTE_USER=&quot; sn eppn&quot; </li></ul></ul><ul><li>Note without the mappings added earlier, no change will occur. </li></ul>
  56. 56. Attribute Filtering <ul><li>Answers the &quot;who can say what&quot; question on behalf of an application. </li></ul><ul><li>Usual examples: </li></ul><ul><ul><li>constraining the possible values of an attribute (e.g. eduPersonAffiliation) </li></ul></ul><ul><ul><li>limiting the scopes/domains an IdP can speak for (e.g. OSU cannot assert faculty@umich.edu) </li></ul></ul><ul><ul><li>limiting custom attributes to particular sources </li></ul></ul>
  57. 57. Default Policy <ul><li>Shared rule for legal affiliation values </li></ul><ul><li>Shared rule for scoped attributes </li></ul><ul><li>Generic policy applying those rules and letting all other attributes through. </li></ul><ul><li>Check /var/log/shibboleth/shibd.log for signs of filtering… </li></ul><ul><li>Combining policies currently a bit buggy in IdP and SP, fix forthcoming. </li></ul>
  58. 58. Add a Source-Based Rule <ul><li>Add a rule to limit acceptance of &quot;sn&quot; to a single IdP: </li></ul><ul><ul><li>$ vi /etc/shibboleth/attribute-policy.xml </li></ul></ul><ul><ul><li>Line 55: </li></ul></ul><ul><ul><li><afp:AttributeRule attributeID=&quot;sn&quot;> </li></ul></ul><ul><ul><li><afp:PermitValueRule xsi:type=&quot;AttributeIssuerString&quot; value=&quot;https://idp N .example.com/idp/shibboleth&quot;/> </li></ul></ul><ul><ul><li></afp:AttributeRule> </li></ul></ul>
  59. 59. Access Control <ul><li>Not formally part of the SP, but cleanly integrated with it via an AccessControl API built into the request processing flow. </li></ul><ul><li>Two implementations are provided: </li></ul><ul><ul><li>.htaccess &quot;require&quot; rule processing </li></ul></ul><ul><ul><li>XML-based policy syntax attached to content via RequestMap </li></ul></ul>
  60. 60. .htaccess Access Control <ul><li>Special rules: </li></ul><ul><ul><li>shibboleth (no authz) </li></ul></ul><ul><ul><li>valid-user (require a session, but NOT identity) </li></ul></ul><ul><ul><li>user (REMOTE_USER as usual) </li></ul></ul><ul><ul><li>group (group files as usual) </li></ul></ul><ul><ul><li>authnContextClassRef, authnContextDeclRef </li></ul></ul><ul><li>&quot;OR&quot; implied unless ShibRequireAll used </li></ul><ul><li>Regular expressions supported using special syntax: </li></ul><ul><ul><li>require rule ~ exp </li></ul></ul>
  61. 61. .htaccess Example <ul><li>Require an entitlement or specific users: </li></ul><ul><ul><li>$ vi /var/www/cgi-bin/.htaccess </li></ul></ul><ul><ul><li>AuthType shibboleth </li></ul></ul><ul><ul><li>ShibRequestSetting requireSession 1 </li></ul></ul><ul><ul><li>require entitlement http://channel8.msdn.com/user </li></ul></ul><ul><ul><li>require user ~ ^staff(1|2)@example.com$ </li></ul></ul>
  62. 62. XML Access Control <ul><li>Portable across servers, mainly an example of what's possible; competing with XACML is not a goal. </li></ul><ul><li>For convenience, embeddable inside RequestMap syntax, but can be externalized. </li></ul><ul><li>Same special rules as .htaccess, adds boolean operators (<AND>,<OR>,<NOT>). </li></ul>
  63. 63. XML Example <ul><li>Require an entitlement or specific users: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 62: </li></ul></ul><ul><ul><li><Host name=&quot;sp N .example.com&quot;> </li></ul></ul><ul><ul><li><Path name=&quot;cgi-bin&quot; authType=&quot;shibboleth&quot; requireSession=&quot;true&quot;> </li></ul></ul><ul><ul><li><AccessControl> </li></ul></ul><ul><ul><li><OR> </li></ul></ul><ul><ul><li><Rule require=&quot;entitlement&quot;> http://channel8.msdn.com/user</Rule> </li></ul></ul><ul><ul><li><RuleRegex require=&quot;user&quot;>^staff(1|2)@example.com$</RuleRegex> </li></ul></ul><ul><ul><li></OR> </li></ul></ul><ul><ul><li></AccessControl> </li></ul></ul><ul><ul><li></Path> </li></ul></ul><ul><ul><li></Host> </li></ul></ul>
  64. 64. <ul><li>END </li></ul>
  65. 65. Session Initiators / Discovery <ul><li>Concepts </li></ul><ul><li>Chains and protocol precedence </li></ul><ul><li>Lazy sessions </li></ul><ul><li>Discovery services </li></ul><ul><li>Internal discovery mechanisms </li></ul>
  66. 66. Session Initiators / Discovery Concepts <ul><li>Session Initiator </li></ul><ul><ul><li>handler that creates a SSO request for an IdP or uses a discovery mechanism to identity the IdP (or both) </li></ul></ul><ul><li>Discovery (in Shibboleth) </li></ul><ul><ul><li>identifying the IdP of a particular user </li></ul></ul><ul><ul><li>can be internal or external, automatic or invasive </li></ul></ul><ul><li>WAYF Service </li></ul><ul><ul><li>old name in Shibboleth for a particular way to do discovery </li></ul></ul><ul><li>Handler Chain </li></ul><ul><ul><li>sequence of handlers that share configuration and run consecutively until &quot;something useful happens&quot; or an error occurs </li></ul></ul>
  67. 67. Simplest Case <ul><li>Single IdP, single protocol, no discovery: </li></ul><ul><ul><li><SessionInitiator </li></ul></ul><ul><ul><li>type=&quot;SAML2&quot; id=&quot;simple&quot; isDefault=&quot;true&quot; </li></ul></ul><ul><ul><li>Location=&quot;/Login&quot; </li></ul></ul><ul><ul><li>entityID=&quot;https://testidp.example.com/idp/shibboleth&quot; </li></ul></ul><ul><ul><li>relayState=&quot;cookie&quot; </li></ul></ul><ul><ul><li>defaultACSIndex=&quot;1&quot; </li></ul></ul><ul><ul><li>template=&quot;bindingTemplate.html&quot; </li></ul></ul><ul><ul><li>/> </li></ul></ul><ul><li>Resembles the typical approach used in 1.3 SP but omits hardcoding the IdP's location. </li></ul>
  68. 68. Intranet Case <ul><li>Single IdP, multiple protocols, no discovery: </li></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; </li></ul></ul><ul><ul><li>id=&quot;Intranet&quot; isDefault=&quot;true&quot; relayState=&quot;cookie&quot; </li></ul></ul><ul><ul><li>entityID=&quot; https://testidp.example.com/idp/shibboleth&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; template=&quot;bindingTemplate.html&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Shib1&quot; defaultACSIndex=&quot;5&quot;/> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul><ul><li>Protocol precedence controlled by order of chain. </li></ul><ul><li>Common properties defined at the top and inherited by chain links. </li></ul>
  69. 69. Favoring Legacy Protocol <ul><li>Switch order of chain: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 105: </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/Login&quot; </li></ul></ul><ul><ul><li>id=&quot;Intranet&quot; isDefault=&quot;true&quot; relayState=&quot;cookie&quot; </li></ul></ul><ul><ul><li>entityID=&quot; https://testidp.example.com/idp/shibboleth&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Shib1&quot; defaultACSIndex=&quot;5&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; template=&quot;bindingTemplate.html&quot;/> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul><ul><li>Still allows either protocol, but if the IdP supports Shibboleth profile of SAML 1, it will be used instead. </li></ul>
  70. 70. Discovery <ul><li>Protocol SessionInitiators work when the IdP is known. </li></ul><ul><li>For consistency, discovery is implemented with alternate SessionInitiators that operate only when the IdP is NOT known. </li></ul><ul><li>A typical federated chain includes one or more &quot;protocol&quot; handlers followed by a single &quot;discovery&quot; handler at the end. </li></ul>
  71. 71. Typical Discovery Methods <ul><li>External Options </li></ul><ul><ul><li>older WAYF model, specific to Shibboleth/SAML1, SP loses control if a problem occurs </li></ul></ul><ul><ul><li>newer SAMLDS model, recently standardized, supports multiple SSO protocols and allows the SP to control the process </li></ul></ul><ul><li>Internal Options </li></ul><ul><ul><li>implemented by an application, followed by a redirect with the entityID </li></ul></ul><ul><ul><li>advanced &quot;Cookie&quot;, &quot;Form&quot;, and &quot;Transform&quot; SessionInitiators </li></ul></ul>
  72. 72. DS Case <ul><li>Multiple protocols, discovery via DS: </li></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/DS&quot; </li></ul></ul><ul><ul><li>id=&quot;DS&quot; isDefault=&quot;true&quot; relayState=&quot;cookie&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; acsByIndex=&quot;false&quot; template=&quot;bindingTemplate.html&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Shib1&quot; defaultACSIndex=&quot;5&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAMLDS&quot; URL=&quot;https://ds.example.com/DS&quot;/> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul><ul><li>Same as intranet case, but omits entityID and adds a &quot;safety net&quot; at the bottom. </li></ul><ul><li>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. </li></ul>
  73. 73. Problems with External Discovery <ul><li>Loss of control, UI fidelity </li></ul><ul><li>Impact of errors </li></ul><ul><li>Choice of IdPs becomes arbitrary: metadata errors have to be handled </li></ul><ul><li>Comprehensiveness is impossible in a world of multiple federations, and the list is too long if there's only one federation </li></ul>
  74. 74. Advanced SessionInitiators <ul><li>Form SessionInitiator </li></ul><ul><ul><li>Crude DS relying on HTML form template, NOT meant to replace the actual DS implementation. </li></ul></ul><ul><li>Cookie SessionInitiator (early in chain) </li></ul><ul><ul><li>Parses _saml_idp cookie maintained by idpHistory feature and sets entityID ahead of other handlers. </li></ul></ul><ul><li>Transform SessionInitiator (early in chain) </li></ul><ul><ul><li>Applies substitution or regex patterns against entityID to turn it into another entityID until metadata is available. </li></ul></ul>
  75. 75. Advanced Example <ul><li>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): </li></ul><ul><ul><li><SessionInitiator type=&quot;Chaining&quot; Location=&quot;/DS&quot; </li></ul></ul><ul><ul><li>id=&quot;DS&quot; isDefault=&quot;true&quot; relayState=&quot;cookie&quot;> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Transform&quot;> </li></ul></ul><ul><ul><li><Subst>https://testidp.$entityID/idp/shibboleth</Subst> </li></ul></ul><ul><ul><li><Regex match=&quot;.+@(.+)&quot;>https://testidp.$1/idp/shibboleth</Regex> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;SAML2&quot; defaultACSIndex=&quot;1&quot; acsByIndex=&quot;false&quot; template=&quot;bindingTemplate.html&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Shib1&quot; defaultACSIndex=&quot;5&quot;/> </li></ul></ul><ul><ul><li><SessionInitiator type=&quot;Form&quot; template=&quot;discoveryTemplate.html&quot;/> </li></ul></ul><ul><ul><li></SessionInitiator> </li></ul></ul>
  76. 76. <ul><li>END </li></ul>
  77. 77. SP Advanced Integration <ul><li>Error Handling </li></ul><ul><li>Logout </li></ul>
  78. 78. Error Handling Approaches <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPErrors </li></ul><ul><li>Default is to output customizable templates divided into a couple of types of errors. </li></ul><ul><ul><li>Templates written in HTML plus simple markup allowing information to be plugged in. </li></ul></ul><ul><ul><li>PLEASE customize these pages. </li></ul></ul><ul><li>Optionally can redirect to a script on errors with parameters identifying the error. </li></ul><ul><ul><li>Major use case: passive SSO failure. </li></ul></ul>
  79. 79. Logout <ul><li>Two types of sign-out operations: local and global. </li></ul><ul><li>Local logout affects only the SP (and possibly applications behind it). </li></ul><ul><li>Global logout includes the IdP and possibly other SPs sharing the session at the IdP. </li></ul><ul><ul><li>Most global/single logout protocols can start at either end. </li></ul></ul>
  80. 80. IdP-initiated Logout <ul><li>Logout protocols that start at the IdP, such as SAML's, are implemented by SingleLogoutService handlers. </li></ul><ul><li>Details are dependent on the protocol, but generally will result in transfer back to the IdP regardless of the outcome. </li></ul>
  81. 81. SP-initiated Logout <ul><li>Relies on a chain of handlers called LogoutInitiators. </li></ul><ul><li>Each handler understands a single SSO protocol and how to perform logout for it. </li></ul><ul><li>The &quot;Local&quot; handler typically runs if nothing else does, and performs a local sign-out operation, ignoring the IdP. </li></ul>
  82. 82. Application Notification <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPNotify </li></ul><ul><li>Applications can be notified when logout occurs by installing scripts to receive redirects or loopback XML messages. </li></ul><ul><li>Notifications allow applications to clean up their state before the SP cleans up its own. </li></ul>
  83. 83. <ul><li>END </li></ul>
  84. 84. SP Virtualization <ul><li>Terminology </li></ul><ul><li>Adding a second vhost-based application </li></ul><ul><li>Clustering </li></ul><ul><li>HTTP virtualization </li></ul>
  85. 85. Terminology <ul><li>Service Provider (physical) </li></ul><ul><ul><li>an installation of the software on a server </li></ul></ul><ul><li>Service Provider (logical) </li></ul><ul><ul><li>web resources viewed externally as a unit </li></ul></ul><ul><ul><li>each entityID identifies exactly one logical SP </li></ul></ul><ul><li>SP Application </li></ul><ul><ul><li>web resources viewed internally as a unit </li></ul></ul><ul><ul><li>each applicationId identifies exactly one logical application </li></ul></ul><ul><ul><li>a user session is bound to exactly one application </li></ul></ul>
  86. 86. Virtualization Concepts <ul><li>A single physical SP can host any number of logical SPs. (virtual hosting) </li></ul><ul><ul><li>A logical SP can then include any number of &quot;applications&quot;. </li></ul></ul><ul><ul><li>Web virtual hosting is often related but is also independent. </li></ul></ul><ul><ul><li>Applications can inherit or override default configuration settings on a piecemeal basis. </li></ul></ul><ul><li>Multiple physical SPs can also act as a single logical SP. (clustering) </li></ul>
  87. 87. Adding an Application <ul><li>Goal: add a second application with its own entityID living on its own virtual host. </li></ul><ul><li>Add the application and map the host to it: </li></ul><ul><ul><li>$ vi /etc/shibboleth/shibboleth2.xml </li></ul></ul><ul><ul><li>Line 55: </li></ul></ul><ul><ul><li><RequestMap applicationId=&quot;default&quot;> </li></ul></ul><ul><ul><li><Host applicationId=&quot;alt&quot;/> </li></ul></ul><ul><ul><li>Line 243: </li></ul></ul><ul><ul><li><ApplicationOverride id=&quot;alt&quot; entityID=&quot;https://altsp N .example.com/shibboleth&quot;/> </li></ul></ul><ul><ul><li></ApplicationDefaults> </li></ul></ul>
  88. 88. Clustering <ul><li>Configure multiple physical installations to share an entityID, and possibly credentials. </li></ul><ul><li>Configuration files often can be identical across servers that share an external hostname. </li></ul><ul><li>Session management: </li></ul><ul><ul><li>For applications already handling this, 2-3 minute sticky sessions usually sufficient. </li></ul></ul><ul><ul><li>SP itself now clusterable via ODBC, soon memcached. </li></ul></ul>
  89. 89. HTTP Virtualization <ul><li>Broadly, it's when the physical connection into a server has a different scheme, hostname, or port than the client sees. </li></ul><ul><li>Not all web servers actually support this! </li></ul><ul><ul><li>&quot;Support&quot; means that the server's internal APIs allow an application to correctly construct an absolute redirect to itself. </li></ul></ul>
  90. 90. HTTP Virtualization <ul><li>The SP relies on the web server to be correctly configured. </li></ul><ul><ul><li>Apache virtual host definitions allow the scheme, hostname, and port to be &quot;overridden&quot; from the physical values. You MUST do this if you expect the SP to work. </li></ul></ul><ul><li>For servers without native support (i.e. IIS), the SP has &quot;gap filling&quot; features allowing the scheme, hostname, and port to be supplied on a per-site basis. </li></ul><ul><ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPISAPI </li></ul></ul>
  91. 91. <ul><li>END </li></ul>
  92. 92. SP Relying Party Configuration <ul><li>Philosophically, goal is to reduce or eliminate IdP-specific settings: </li></ul><ul><ul><li>deployment profiles and best practices </li></ul></ul><ul><ul><li>uniform entityID and metadata </li></ul></ul><ul><ul><li>uniform credentials </li></ul></ul><ul><li>Counter to this goal are federation-specific approaches to naming, certificates, and security requirements. </li></ul><ul><li>Using PKI across federations is a major impediment to SP deployment and interfederation. </li></ul>
  93. 93. Relying Party Settings <ul><li>https://spaces.internet2.edu/display/SHIB2/NativeSPRelyingParty </li></ul><ul><li>Most settings are security- or connectivity-related: </li></ul><ul><ul><li>signing and encryption rules, algorithms </li></ul></ul><ul><ul><li>selecting among multiple keys or certificates </li></ul></ul><ul><ul><li>authentication types and connection timeouts for back-channel communications to IdPs </li></ul></ul><ul><ul><li>rules for signing or encryption imposed on messages from IdPs </li></ul></ul>
  94. 94. Relying Party Selection <ul><li>API to acquire settings is metadata-based and not as flexible as it should be </li></ul><ul><li>Primary matching based on IdP's entityID </li></ul><ul><li>Secondary matching proceeds up through any enclosing EntitiesDescriptor groups. </li></ul><ul><ul><li><md:EntitiesDescriptor Name=&quot;https://thefederation.com&quot;> </li></ul></ul><ul><ul><li><md:EntitiesDescriptor Name=&quot;https://thefederation.com/group1&quot;> </li></ul></ul><ul><ul><li><md:EntityDescriptor entityID=&quot;https://sp.example.com/shibboleth&quot;/> </li></ul></ul><ul><ul><li></md:EntitiesDescriptor> </li></ul></ul><ul><ul><li></md:EntitiesDescriptor> </li></ul></ul>
  95. 95. Credential Selection Example <ul><li>Most common use case today. </li></ul><ul><li>With 2.0, credentials can be annotated with a name used when looking up the right set to use: </li></ul><ul><ul><li><ApplicationDefaults …> </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><ul><li><RelyingParty Name=&quot;https://theotherfederation.com&quot; keyName=&quot;other&quot;/> </li></ul></ul><ul><ul><li>… </li></ul></ul><ul><ul><li><CredentialResolver type=&quot;Chaining&quot;> </li></ul></ul><ul><ul><li><CredentialResolver type=&quot;File&quot; </li></ul></ul><ul><ul><li>key=&quot;sp-key.pem&quot; certificate=&quot;sp-cert.pem&quot;/> </li></ul></ul><ul><ul><li><CredentialResolver type=&quot;File&quot; keyName=&quot;other&quot; </li></ul></ul><ul><ul><li>key=&quot;sp-key.pem&quot; certificate=&quot;other-cert.pem&quot;/> </li></ul></ul><ul><ul><li></CredentialResolver> </li></ul></ul><ul><ul><li></ApplicationDefaults> </li></ul></ul>
  96. 96. Complications <ul><li>Settings can only be chosen based on the IdP once the IdP is known. </li></ul><ul><li>Sometimes settings needed in contexts in which the IdP is not known: </li></ul><ul><ul><li>legacy WAYF model </li></ul></ul><ul><ul><li>SAML 2 Enhanced Client profile </li></ul></ul><ul><li>Moral of the story: most settings simply shouldn't vary to avoid needless complexity. </li></ul>
  97. 97. <ul><li>END </li></ul>
  98. 98. Campus SSO Support <ul><li>OSU Experiences </li></ul><ul><li>Pros </li></ul><ul><li>Cons </li></ul><ul><li>Strategies and Issues </li></ul>
  99. 99. OSU Deployment <ul><li>Dates to 2004, accelerated deployment during 2005. </li></ul><ul><li>Migration from legacy software at 50+ departmental servers completed by March 2007. </li></ul><ul><li>Currently 141 locally registered SPs, server count closer to 100. </li></ul><ul><li>Two servers handle 80-130,000 logins/day. </li></ul><ul><li>0.4 FTE </li></ul>
  100. 100. Pros <ul><li>Feature-rich without being fragile </li></ul><ul><li>Unified internal/external solution </li></ul><ul><li>Clusters/scales efficiently </li></ul><ul><li>Attribute support without requiring LDAP </li></ul><ul><li>Enforces proper application design </li></ul>
  101. 101. Cons <ul><li>Certificates and XML </li></ul><ul><li>Lack of web server expertise </li></ul><ul><li>Enforcing entityID sanity </li></ul><ul><li>Crazy hosting practices </li></ul><ul><li>Zero-effort expectations </li></ul><ul><ul><li>configuration effort, especially error handling </li></ul></ul><ul><ul><li>using support channels </li></ul></ul><ul><ul><li>metadata and software maintenance </li></ul></ul>
  102. 102. Local Documentation <ul><li>Put in a local context and set expectations </li></ul><ul><li>Pointers to support resources, preferably not your email address </li></ul><ul><li>Step by step process with starter files or a custom installer/package </li></ul><ul><ul><li>metadata </li></ul></ul><ul><ul><li>routing requests to IdP </li></ul></ul><ul><ul><li>local attributes and conventions </li></ul></ul><ul><ul><li>error templates </li></ul></ul>
  103. 103. Attributes, Attributes, Attributes <ul><li>Precise definitions </li></ul><ul><li>Local semantics </li></ul><ul><li>Conventions for header names </li></ul><ul><li>Influence developer practices </li></ul>
  104. 104. Process <ul><li>Certificate strategy: take advantage of 2.0 keypair generation </li></ul><ul><li>SP registration: manual or automated </li></ul><ul><li>IdP metadata: local vs. reuse of federation; understanding the security and operational issues </li></ul><ul><li>Policies for attribute release: avoiding &quot;policy by sysadmin&quot; </li></ul><ul><li>Awareness of updates and EOL timelines </li></ul>
  105. 105. Federation Implications <ul><li>Few local services may be interested in federating, and few of those may be ready. </li></ul><ul><li>Local strategy needn't focus on it, but shouldn't preclude it either. </li></ul><ul><ul><li>single IdP </li></ul></ul><ul><ul><li>use of federation metadata </li></ul></ul><ul><ul><li>federation-friendly design practices </li></ul></ul><ul><li>InCommon simplifying process of federating existing sites without reissuing credentials. </li></ul><ul><li>Campus-level WAYF/DS quite sensible. </li></ul>
  106. 106. <ul><li>END </li></ul>
  107. 107. Federating Applications <ul><li>Definitions </li></ul><ul><li>Policy or Wing It? </li></ul><ul><li>Authentication and Identifiers </li></ul><ul><li>Discovery </li></ul><ul><li>Introduction Problem </li></ul><ul><li>End User Support </li></ul>
  108. 108. Definitions <ul><li>Federation of an application </li></ul><ul><ul><li>Accepting identity attributes from multiple, distinct external sources that do not share a common identity namespace. </li></ul></ul><ul><ul><li>Protocol agnostic (relying on OpenID is federation). </li></ul></ul><ul><ul><li>Implies some degree of externalization, but much may be left internal. </li></ul></ul>
  109. 109. Policy vs. Expediency <ul><li>Address everything up front contractually or rely on remediation strategies through existing channels? </li></ul><ul><li>Level of Assurance </li></ul><ul><ul><li>Formal means of assessing and articulating proofing, credentialing, and authentication processes. </li></ul></ul><ul><ul><li>Contrast with SSO within our organizations. </li></ul></ul><ul><ul><li>Contrast with non-federated alternatives. </li></ul></ul>
  110. 110. Externalizing Authentication <ul><li>Most visible, well understood part </li></ul><ul><li>Analagous to making SSO work locally </li></ul><ul><li>Consider the cost of limiting the application to a single federation protocol </li></ul><ul><li>Consider dynamic provisioning of identities at the time of login </li></ul>
  111. 111. Identifiers <ul><li>Must determine application requirements for different kinds of identifiers. </li></ul><ul><li>Assumptions on length, character set fall apart in a federated model. </li></ul><ul><li>Lots of subtleties: </li></ul><ul><ul><li>uniqueness </li></ul></ul><ul><ul><li>persistence </li></ul></ul><ul><ul><li>reassignment </li></ul></ul><ul><ul><li>human readability </li></ul></ul><ul><ul><li>social knowledge </li></ul></ul>
  112. 112. Common Identifiers <ul><li>local userid/netid </li></ul><ul><ul><li>usually readable, persistent but not permanent, often reassigned, not unique </li></ul></ul><ul><li>email address </li></ul><ul><ul><li>usually readable, persistent but not permanent, often reassigned, unique </li></ul></ul><ul><li>eduPersonPrincipalName </li></ul><ul><ul><li>usually readable, persistent but not permanent, can be reassigned, unique </li></ul></ul><ul><li>eduPersonTargetedID / SAML 2.0 persistent ID </li></ul><ul><ul><li>not readable, semi-permanent, not reassigned, unique </li></ul></ul><ul><li>OpenID </li></ul><ul><ul><li>usually somewhat readable, usually persistent, may be reassignable, unique </li></ul></ul>
  113. 113. eduPersonTargetedID <ul><li>Legacy attribute placeholder for the SAML 2.0 persistent NameID format: </li></ul><ul><ul><li>opaque </li></ul></ul><ul><ul><li>pairwise (IdP/SP, could be shared by >1 SP) </li></ul></ul><ul><ul><li>original motivation was privacy, but strongest features are lack of reassignment and immunity to name changes </li></ul></ul><ul><ul><li><saml:NameID </li></ul></ul><ul><ul><li>Format=&quot;urn:oasis:names:tc:SAML:2.0:nameid-format:persistent&quot; </li></ul></ul><ul><ul><li>NameQualifier=&quot;https://testidp.example.com/idp/shibboleth&quot; </li></ul></ul><ul><ul><li>SPNameQualifier=&quot;https://testsp.example.com/shibboleth&quot; </li></ul></ul><ul><ul><li>>anystringthatcouldbeup256chars</saml:NameID> </li></ul></ul><ul><ul><li>https://testidp.example.com/idp/shibboleth!https://testsp.example.com/shibboleth!anystringthatcouldbeup256chars </li></ul></ul>
  114. 114. eduPersonTargetedID <ul><li>Minimally supported so far: </li></ul><ul><ul><li>not easily stored in LDAP </li></ul></ul><ul><ul><li>can be generated from a hash, but with drawbacks: </li></ul></ul><ul><ul><ul><ul><li>value tied to inputs (underlying userid, name of SP) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>can't be refreshed to maintain privacy </li></ul></ul></ul></ul><ul><ul><ul><ul><li>hard to reverse efficiently </li></ul></ul></ul></ul><ul><ul><li>ideally generated randomly and stored and managed in a database, but adds state and additional backup requirements to IdP </li></ul></ul>
  115. 115. Discovery <ul><li>Two kinds of applications: </li></ul><ul><ul><li>relatively balanced audience across IdPs </li></ul></ul><ul><ul><li>overweighted to a single IdP with a few outliers </li></ul></ul><ul><li>Most campus applications are the latter, making discovery a usability issue (or so some argue). </li></ul><ul><li>Easy solution is also a poor one: </li></ul><ul><ul><li>&quot;Click here if you're not from Foobar U&quot; </li></ul></ul><ul><ul><li>I'll happily phish your users, just don't do it to mine </li></ul></ul>
  116. 116. Introduction Problem <ul><li>More pronounced with federation, but can arise with SSO alone. </li></ul><ul><li>Traditional apps have access to their entire user population in advance. </li></ul><ul><li>Assigning roles or adding access involves a &quot;people picker&quot;. </li></ul><ul><li>There is no federated people picker, and privacy limits the ability to build one in the general sense. </li></ul>
  117. 117. Introduction Problem <ul><li>Basic use case: </li></ul><ul><ul><li>I want to add person X to a group or give them to access a resource. </li></ul></ul><ul><li>What is X? Can it be known in advance? If not, is strong security even possible? </li></ul><ul><li>Next major problem frontier. </li></ul>
  118. 118. End User Support <ul><li>Supporting a federated application from the IdP side is a dead end (e.g. OpenID). </li></ul><ul><li>Applications MUST provide adequate feedback to users and prepare their support staff for the change. </li></ul><ul><li>I argue they also must own access issues even if they ultimately get blamed on the IdP, or federation will never scale. </li></ul>
  119. 119. <ul><li>END </li></ul>
  120. 120. SAML Metadata <ul><li>Scope </li></ul><ul><li>Terminology </li></ul><ul><li>Migration Support </li></ul><ul><li>Trust Management </li></ul><ul><li>Identity Provider Metadata </li></ul><ul><li>Service Provider Metadata </li></ul>
  121. 121. Scope <ul><li>Entities in hierarchical groups </li></ul><ul><li>Peer roles and protocol support </li></ul><ul><li>Profile support and endpoint locations </li></ul><ul><li>Advertising extension support </li></ul><ul><li>Trust management </li></ul><ul><li>Encryption keys </li></ul><ul><li>Attribute support and requirements </li></ul><ul><li>Contact information </li></ul>
  122. 122. Scope <ul><li>Not in Scope: </li></ul><ul><ul><li>Authorization policy </li></ul></ul><ul><ul><li>Security policy </li></ul></ul><ul><li>Maybe in Scope: </li></ul><ul><ul><li>Federation-asserted attributes about members </li></ul></ul><ul><ul><li>Profiles for non-SAML protocol families </li></ul></ul>
  123. 123. Other Relevancies <ul><li>WS-Federation metadata proposals </li></ul><ul><li>WS-MetadataExchange </li></ul><ul><li>XRI and XRDS (used by OpenID) </li></ul><ul><li>DNSSEC, SRV records </li></ul>
  124. 124. Terminology <ul><li>EntityDescriptor </li></ul><ul><ul><li>A distinct SAML-supporting system, can be collected into EntitiesDescriptor groups. </li></ul></ul><ul><li>Role </li></ul><ul><ul><li>A SAML functional role played by a system (IdP, SP, AA, PDP, etc.) </li></ul></ul><ul><li>Protocol </li></ul><ul><ul><li>A set of profiles grouped into a single &quot;family&quot; (SAML 1.0, SAML 1.1, SAML 2.0, etc.) </li></ul></ul><ul><li>Endpoint </li></ul><ul><ul><li>A descriptor identifying how to invoke a service supporting a particular profile. </li></ul></ul><ul><li>KeyDescriptor </li></ul><ul><ul><li>A signing or encryption key, underspecified syntax. </li></ul></ul>
  125. 125. Supporting Migration <ul><li>Metadata use backported to SAML 1.1 by Shibboleth project, standardized at OASIS. </li></ul><ul><li>Entity roles tagged with supported protocols, allowing new protocols to be added without affecting existing deployments. </li></ul><ul><li>Supports multiple keys for key rollover. </li></ul>
  126. 126. Trust Management <ul><li>Agreement </li></ul><ul><ul><li>Vehicle for communicating who can be trusted and how to establish that trust at a technical level. </li></ul></ul><ul><li>Less Agreement </li></ul><ul><ul><li>How to communicate trust and whether to do so absent additional infrastructure. </li></ul></ul><ul><ul><li>Aggregation of metadata. </li></ul></ul><ul><li>Generally: peer to peer vs. additional PKI </li></ul>
  127. 127. Trust Management <ul><li>Shibboleth Implementation and Goals </li></ul><ul><ul><li>Produce a well-documented and understandable set of approaches accomodating different communities. </li></ul></ul><ul><ul><li>Pursue a disaggregation of PKI from the SAML runtime to enable federation to scale without a global PKI. </li></ul></ul><ul><ul><li>Collaborate with vendors on profiles to standardize approaches. </li></ul></ul>
  128. 128. Identity Provider Metadata <ul><li>Typically include IdP and AA roles, reflecting attribute query use in Shibboleth </li></ul><ul><li>Endpoints for SSO requests, queries, logout, advanced SAML profiles </li></ul><ul><li>Signing/encryption keys </li></ul><ul><li>Supported NameID formats, Attributes </li></ul><ul><li>Contact information </li></ul><ul><li>Proposal made to carry organization logos </li></ul>
  129. 129. Service Provider Metadata <ul><li>Role representing notion of a SAML-enabled web site supporting SSO profiles </li></ul><ul><li>Endpoints for SSO responses, logout, advanced SAML profiles </li></ul><ul><li>Signing/encryption keys </li></ul><ul><li>Supported NameID formats </li></ul><ul><li>Rudimentary support for expressing &quot;service levels&quot; and attribute requirements </li></ul><ul><li>Contact information </li></ul>

×