Shibboleth @ the MPI CLARIN-D Tutorial, AAI

September 8th, 2011

Willem Elbers The Language Archive – Max Planck Institute for Psycholinguistics

Nijmegen, The Netherlands

Agenda

•  About shibboleth •  MPI overview

•  Identity Providers •  Service Providers •  Federations

•  Default Service Provider •  Lazy Service Provider •  Servlet security filter •  WAYF improvements •  Shibboleth pointers •  Conclusion

About shibboleth

•  Shibboleth: http://shibboleth.internet2.edu/ •  Single sign-on solution •  Mainly used for web-application security •  Based on SAML •  Since version 2.3 integrated support for non-browser based authentication (since 2.x available as a plugin) •  Session used to manage authentication state

•  Identity Provider (IDP) •  Authenticates a user •  Managed by the users home organization •  Web application

•  Service Provider (SP) •  Authorizes a user •  Managed by the applications organization •  Integrated into web server

About shibboleth

•  Federations •  Groups of IDPs an SPs trusting each other

•  Where are you from (WAYF) / Discovery service (DS) •  Page to allow end-users to easily find and select their home organization IDP

•  IDPs expose attributes related to the user to the SP

About shibboleth

WAYF  

AAI  Protected  Resource  

Servlet  Container  

Webserver  

Service  Provider  

AAI  enabled  home  organiza=on  

Iden=ty  Provider  

Authen=ca=on  system  

User  

User  interac=on  Redirect  

request  wayf?  

my  idp  

who  are  you?  willem  elbers  

session  +  aFributes  

response  authen=cate  

user  expose  

aFributes  

About shibboleth

•  Trust relation between IDP and SP •  A SP has to trust an IDP to accept users logged in through that IDP •  A IDP has to trust an SP in order to allow users to be redirected for login from an SP / WAYF / DS

•  Metadata •  A metadata file contains IDPs and SPs that trust each other based on their entityIDs •  The trust relation in shibboleth is established by exchanging public keys •  Multiple metadata sources can be aggregated

MPI Overview

•  We are running 4 Identity Providers •  idp-mpi: MPI-PL identity provider

•  AD+AMS2 users •  idp-mpg: MPG wide identity provider

•  AD only users •  idp-surf: Authenticate to dutch educational organizations

•  AD only users •  idp-clarin: Clarin guest users

•  clarin.eu website only users

•  We are running 3 Service Providers •  MPI production SP •  Clarin production SP •  MPI+Clarin (lux17 staging) SP

MPI Overview

•  We participate in a number of federations •  Full participation (IDP + SP)

•  MPI, MPGAAI, SURFFED and CLARIN •  SP only participation

•  DFN, HAKA, KALMAR

•  Our IDPs participate in a single federation

•  Our SPs can participate in multiple federations

•  Federation metadata is available at idp.mpi.nl/metadata •  This is chained in the SP metadata provider configuration

•  Altogether this results in a fairly complex setup

•  Both from a technical point of view and from a policy point of view

MPI Overview

AD  AMS2   Clarin.eu  

MPI   MPGAAI   SURF   CLARIN  

MPI   MPGAAI   SURFFED   CLARIN   DFN   HAKA   KALMAR  

MPI  Produc=on  (corpus1)  

MPI  Staging  (lux17)   CLARIN.EU  

User  store  

Service  Providers  

Federa=ons  

Iden=ty  Providers  

What do we protect?

•  Data •  All data is directly accessible through apache •  Metadata is publicly accessible (link) •  Resources are usually protected (link) •  Default shibboleth SP configuration

•  Web Applications •  (Java) Web applications are usually protected •  Default user “anonymous” if no shibboleth session is available •  Accomplished with lazy service provider together with a servlet security filter: SHHAA

•  Simple HTTP Header Authentication & Authorization

•  Example: Component Registry (link)

Default SP configuration

•  Load shibboleth module in apache LoadModule mod_shib !

!…/shibboleth-sp/lib/shibboleth/mod_shib_22.so! • Configure protected directories (httpd.conf):

<Directory /data/corpora>! AuthType shibboleth ! ShibRequireSession On! ShibUseHeaders On! AllowOverride Limit FileInfo AuthConfig! AuthName "Login for Access to Media"! Deny from all! satisfy any! <Files ~ "\.(imdi|cfg|hry|dbf|xsd|pen|xml)$">! Allow from all! </Files>! Options FollowSymLinks!</Directory>!!

Default SP configuration

•  Session Initiators •  Configure the SP behavior when no session is available •  Configured in shibboleth2.xml •  First match or default is used

•  Fixed IDP:

•  WAYF: <SessionInitiator !

!type="Chaining” Location="/DS" id="DS" relayState="cookie">! …! <SessionInitiator type="SAMLDS" !

! ! !URL="http://idp.mpi.nl/DS/WAYF"/>! </SessionInitiator>! hFps://wiki.shibboleth.net/confluence/display/SHIB2/Na=veSPSessionIni=ator  

<SessionInitiator !!type="Chaining" Location="/Login" isDefault="true" !!id="Intranet” relayState="cookie" !!entityID="https://idp.clarin.eu">!

…!</SessionInitiator>!

Default SP configuration

•  Metadata provider chaining •  Configured in shibboleth2.xml

<MetadataProvider type="Chaining">!! <MetadataProvider ! type="XML" !

!uri="http://idp.mpi.nl/metadata/SurfFed-Prod-metadata.xml" !!backingFilepath="/…/SurfFed-Prod-metadata.xml" !!reloadInterval="7200"/>!

! …!! <MetadataProvider !

!type="XML" !!uri="http://idp.mpi.nl/metadata/mpgaai-metadata.xml" !!backingFilePath="/…/mpgaai-metadata.xml" !!reloadInterval="7200"/>!

!</MetadataProvider>!  

Web application configuration

•  Java servlets are mapped to paths on the webserver •  Example: Imdi Browser à /ds/imdi_browser •  Mod_jk to connect the servlet container (tomcat) to the webserver (apache) •  Mount (../apache/conf/mod_jk.conf):

!JkMount /ds/* worker1!•  Worker (…/apache/conf/workers.properties):

!worker.worker1.type=ajp13!!worker.worker1.host=localhost!!worker.worker1.port=8009!!worker.worker1.lbfactor=50!!worker.worker1.socket_keepalive=1!

•  AJP connector (…/tomcat/conf/server.xml): <Connector !

!port="8009”!!enableLookups="false”!!redirectPort="8443”!!protocol="AJP/1.3”!!URIEncoding="UTF-8" />!

!

Lazy Service Providers

•  A lazy service provider: •  Exports all matched shibboleth attributes as environment variables / HTTP headers in the web server •  Does not block access when there is no valid shibboleth session •  Does not actively redirect a user to an IDP

•  Load shibboleth module in apache LoadModule mod_shib !

!…/shibboleth-sp/lib/shibboleth/mod_shib_22.so!!

•  How to configure a lazy service provider (httpd.conf): <Location /ds/imdi_browser>! AuthType shibboleth! ShibRequireSession Off! ShibUseHeaders On! Satisfy All! Require shibboleth!</Location> !

Servlet Security Filter

•  What is the security filter responsible for? •  Our web applications use the REMOTE_USER property in the servlet security context •  Configure a shibboleth attribute to map to the REMOTE_USER property •  If this shibboleth attribute is not available, redirect to the IDP login or WAYF page •  logout support

•  Configuration of this filter •  Include the mpg-shhaa.jar in the web application •  Documentation: https://aai2.rzg.mpg.de/secure/shhaa/site/index.html •  Availability

Servlet Security Filter

•  Use the security filter in the web application (web.xml):

•  All requests, matching the url pattern, will be processed by the filter first

•  Filter order is important!

•  Use getRemoteUser() in javax.servlet.http.HttpServletRequest

<filter>! <filter-name>AAIFilter</filter-name>! <filter-class>de.mpg.aai.shhaa.AuthFilter</filter-class>!</filter> !<filter-mapping>! <filter-name>AAIFilter</filter-name>! <url-pattern>/*</url-pattern>!</filter-mapping> !

Servlet Security Filter

•  Configure shhaa.xml

•  Multiple attributes can be configured to map to the username, the first match is used!

<authentication>!!<shibheader>!! !<username>eduPersonPrincipalName</username>!!</shibheader>!!<fallback>!! !<username>anonymous</username>!!</fallback>!

<sso action="lI">!! !http://lux16.mpi.nl/Shibboleth.sso/Login!!</sso>!

<slo action="lO">!! !http://lux16.mpi.nl/Shibboleth.sso/Logout!!</slo>!

</authentication>!

Servlet Security Filter

•  Advantages of this approach •  Backwards compatibility with our old approach •  Easily allow anonymous read-only access to the web applications •  Configure login endpoint for each web application

•  Improvements

•  Check the attribute set provided by an IDP against a set of required attributes for the Service provider •  Present a descriptive error message if the IDP does not publish the required attributes

•  Disadvantages •  Based on HTTP headers instead of server environment variables

WAYF improvements

•  We have some issues with the standard shibboleth WAYF page •  Most end-users do not know about the concept of federations •  This makes the default WAYF difficult to use in a multi-federation setup •  Not really fancy •  example

•  We have been looking into the possibility to use discojuice •  http://discojuice.simplesamlphp.org/ •  IDPs presented in a flat list, ordered on weight, recent usage and country / geo location •  Attach higher weight to “important” IDPs •  Easily searchable list •  example

DiscoJuice

•  Requirements •  requires a list of IDP entityIDs enchriched with geospatial information and an optional weight •  JSON format instead of xml

•  We transform our shibboleth metadata to discojuice JSON •  extract all entityIDs and SSOSignOn urls •  Use the SSOSignOn url to do a geo-ip lookup to make a guess about the geo location of that IDP •  Store the IDP geo information together with the entityID and a nice name in the discojuice JSON file

•  Shibboleth metadata •  JSON example

DiscoJuice

•  Configuration •  Publish the discojuice files •  Publish the discojuice JSON metadata file •  Configure discojuice(options variable in idp.html) with a proper JSON metadata file •  Configure your shibboleth DS service to use discojuice

•  Configure the SHHAA filter to use the new DS:

<SessionInitiator type="Chaining" Location="/Disco" ! !! !id="Disco" relayState="cookie”>!! !… !!

<SessionInitiator type="SAMLDS" URL="https://! !! !lux16.mpi.nl/discojuice/idp.html"/>!

</SessionInitiator>!

<sso action="lI">!!http://lux16.mpi.nl/Shibboleth.sso/Disco!

</sso>!

Shibboleth pointers

•  Beware for duplicate IDP entries in your metadata •  The first IDP entityID entry in the chained metadata will be used, regardless of the federation it belongs to

•  SP attribute map configuration (attribute-map.xml) •  SAML1 and SAML2 naming •  nameFormats •  Our mapping for eduPersonPrincipalName:

<Attribute !!name="urn:mace:dir:attribute-def:eduPersonPrincipalName" !id="eduPersonPrincipalName"/>!

<Attribute !!name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" !!!id="eduPersonPrincipalName"/>!

<Attribute !!name="urn:mace:dir:attribute-def:eduPersonPrincipalName" !nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" !!id="eduPersonPrincipalName"/>!

default  nameFormat:  SAML1  =  urn:mace:shibboleth:1.0:aFributeNamespace:uri  SAML2  =  urn:oasis:names:tc:SAML:2.0:aFrname-­‐format:uri  

hFps://wiki.shibboleth.net/confluence/display/SHIB2/Na=veSPAFributeExtractor  

Shibboleth pointers

•  Expired metadata •  Metadata can expire if a validUntil attribute is specified in the metadata root element •  We didn’t notice any clear message in the shibboleth sp log file (not running DEBUG log level) •  Errors indicating that the selected entityID could not be found

•  Firefox SAML tracer plugin •  https://addons.mozilla.org/nl/firefox/addon/saml-tracer/ •  demo

Conclusion

•  In principle a good solution for browser based / user driven single sign-on.

•  Non browser based / user driven interaction possible, but difficult in practice

•  Problem detection in a complex setup not trivial

•  Existing WAYF difficult for end users. •  Discojuice WAYF frontend looks promising

•  Can be difficult to unify our attribute requirements with federation / idp requirements

Questions

Thank  you  for  your  aFen=on