Shibboleth Service Provider Workshop

Shibboleth Service Provider Workshop
Bart Ophelders - Philip Brusten June 2010

Shibboleth Service provider workshop
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Acknowledgements What's new in Shibboleth 2 – Chad La Joie
[SAMLConf] Liberty interoperability testing: Shibboleth 2.0 InstallFest Service Provider Material – Ann Arbor, MI SP Hands-on Session – SWITCH

Program Introduction: “What is Shibboleth?”
Shibboleth 2.x: “What has changed?” Concept of Federation Resource Registry A word on ADFS Installation Bootstrapping SP Configuration

Introduction: “What is Shibboleth?”
Quote from The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.

Introduction: “What is Shibboleth?”
Terminology Authentication: says who we are Authorization: says which resource we can access SP: Service Provider (Resource) IdP: Identity Provider (Home organisation) WAYF: Where Are You From DS: Discovery Service

Architecture Shibboleth v1.3
HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver User Agent/Browser Components: Identity Provider (IdP) – Service Provider (SP) – Where Are You From (WAYF) – User Agent (UA)

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser SAML1.1 profile: Browser/Artifact Initial request from UA to document X No active Shibboleth session, UA redirected to WAYF

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser WAYF asks UA to choose an IdP (if not already set in cookie) Redirect UA to selected IdP

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser IdP prompts the UA for credentials (Username/Password, x509, digipass, etc). IdP uses backend to verify credentials (LDAP, ADDS, SQL, etc)

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser IdP resolves attributes for the authenticated principal and creates SAML assertion (authentication & attribute statement) Redirects UA with references to these assertions (Artifacts).

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser Shibboleth service or daemon dereferences the Artifacts on a secure backchannel with SSL mutual authentication. Invisible for the UA.

HTTP redirect WAYF HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser The Shibboleth service verifies and filters the information and gives it to the Shibboleth module (via RPC or TCP). The Shibboleth module or Webserver will authorise the principal.

HTTP redirect WAYF HTTP interaction Service Provider 2 Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser The active sessions with every component will provide the single sign-on experience.

Shibboleth 2.x: “What has changed?”
General SAML2 protocols Authentication Request Protocol (SP initiated) Force re-authentication Passive authentication Assertion Query and Request Protocol Artifact Resolution Protocol Single Logout Protocol (Not supported by the IdP yet) NameID Management Protocol NameID Mapping Protocol Encryption and signing of sensitive information Distributed configuration (pull) Federation Metadata Attribute-map Attribute-filter

Identity Provider Own authentication modules LDAP Kerberos IP-based PreviousSession (SSO) REMOTE_USER (cfr. CAS) No SAML2 force authentication Very flexible attribute resolving Very flexible attribute filtering (with constraints) Clean audit logs etc

Discovery Service Successor of WAYF SAML2 Identity Provider Discovery Profile Multi-federation support

Service Provider Multi-protocol support New attribute filtering policy language Support for ODBC based storage of state Significant performance improvements

Architecture Shibboleth v2.x
HTTP redirect DS HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser SAML2.0 profile: Web browser SSO + HTTP POST binding Initial request from UA to document X No active Shibboleth session, UA redirected to DS

HTTP redirect DS HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver SP takes back control Identity Provider User Agent/Browser DS asks UA to choose an IdP (if not already set in cookie) Redirect UA back to SP with selected IdP as parameter.

HTTP redirect DS HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser SP sends SAML Authentication request to the IdP. IdP prompts the UA for credentials, if necessary. IdP uses backend to verify credentials (LDAP, ADDS, SQL, etc)

HTTP redirect DS HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser SAML response Authentication statement Attribute statement The IdP resolves and filters the principal’s attribute information and constructs a SAML assertion. This assertion can optionally be signed and/or encrypted. Next, the IdP POSTs a response to the SP.

HTTP redirect DS HTTP interaction Service Provider Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser No callback! The Shibboleth service decrypts, verifies and filters the response and gives it to the Shibboleth module (via RPC or TCP). The Shibboleth module or Webserver will authorise the principal.

HTTP redirect DS HTTP interaction Service Provider 2 Webserver Shibboleth module x Shibboleth service Identity Provider Webserver Identity Provider User Agent/Browser Again, the active sessions with every component will provide the single sign-on experience.

Concept of Federation Group of entities, both IdPs and SPs.
Can map on existing Associations (e.g.: BELNET, Associatie K.U.Leuven, K.U.Leuven, etc) Toledo App X K.U.Leuven W&K App Y … K.U.Leuven App Z App Z … Federation K.U.Leuven Federation Associatie K.U.Leuven

Concept of Federation Benefits Metadata Scalable Simplifies things
WAYF service (IdP discovery) Metadata Describes entities (protocol support, contact information, etc) PKI management Trust Since Shibboleth v2.x = single point of trust Digitally signed

Resource Registry Metadata management tool Adapted for K.U.Leuven
Based on open source from SWITCH and modified by INTIENT and K.U.Leuven Adapted for K.U.Leuven Multi-federation support Identity Provider 1-many link Service Provider 1-many link

Resource Registry

Resource Registry For now only internal use
In a later stage available for: Resource Registry Administrators To approve resources from a certain IdP Resource Administrators For administering SP information (self-service) Home Organisation Administrators For administering IdP information (self-service) Federation Administrators Signing metadata file Roles can be assigned independently

Resource Registry Currently hosting: Federation K.U.Leuven
Federation Associatie K.U.Leuven Federation K.U.Leuven – UZLeuven Test federation K.U.Leuven

A word on ADFS Active Directory Federation Services v1
Part of Microsoft Windows Server 2003 R2 WS-Federation Passive Requester Profile (WS-F PRP) Shibboleth v1.3 has implemented “WS-Federation: Passive Requestor Interoperability Profile” specification for both IdP & SP Two ways of working NT-Token based Claim based

A word on ADFS E.g. Implementation at K.U.Leuven Identity Provider
ADFS Web Agents IdP K.U.Leuven Webserver Identity Provider FS Account partners K.U.Leuven Resources - OWA - EVault - Sharepoint - etc OWA TRUST TRUST EVault TRUST Sharepoint TRUST

A word on ADFS

A word on AD FS 2.0 Version 2.0 Officially released on 5 May 2010
Windows Server 2008 and Windows Server 2008 R2 Only claims based Compatible with ADFS v1.0 Liberty Interoperable Implementation Tables SAML2.0 operational modes: IdP lite SP lite

A word on AD FS 2.0

A word on AD FS 2.0 Identity Providers Application WIF STS STS Token
5) Use claims in token Windows Live ID Other Application WIF STS STS 4) Submit token Token 1) Access application and learn token requirements 3) Authenticate user and get token for selected identity Token Internet Browser or Client CardSpace 2.0 2) Select an identity that matches those requirements User Shamelessly copied from David Chappell’s presentation at TechEd 2009

Environment RedHat Enterprise Linux 5.5 (Tikanga) Debian 5.0 (Lenny)
Windows Server 2008 R2 Username: “shib” / “root” Passwords: Remote Access Linux: ssh Windows: Remote desktop

Environment RedHat Enterprise Linux 5.5 (Tikanga) Debian 5.0 (Lenny)
8 virtual machines DNS: worksh-rh-N.cc.kuleuven.be IP: N Debian 5.0 (Lenny) 4 virtual machines DNS: worksh-db-N.cc.kuleuven.be IP: N Windows Server 2008 R2 10 virtual machines DNS: worksh-w8-N.cc.kuleuven.be IP: N

Environment Shibboleth IdP DNS: worksh-idp.cc.kuleuven.be IP: 10.2.4.9
(only accessible through VMs: /24)

Environment Shibboleth standard base $WORKSH_HOST = worksh-[rh|db|w8]-N.cc.kuleuven.be

Environment Key/Certificate generation - We’ve done it for you 
Webserver Located at $PKI Signed by TerenaSSL CA Shibboleth SP Self-signed worksh-idp.cc.kuleuven.be: /home/shib/ShibbolethSPWorkshop/certificates/shibboleth-sp Certificate: sp-[rh|db|w8]-N-cert.pem Key: sp-[rh|db|w8]-N-key.pem Save at $PKI Test certificates openssl x509 –in $cert –issuer –noout

SSL certificates Use of self-signed certificates in backend
No need for commercial certificates Longer lifetime No truststore to maintain for commercial CAs Revocation (just remove certificate) Trustbase of commercial signed certificates can become quite large Separate certificate for front- and backend

Environment Tools Check your time now! Always work case sensitive!
An absolute must: Syntax friendly editor RHEL: vim Debian: vim Windows: notepad++ or SciTE HTTP client RHEL: links Debian: links Windows: local browser SCP or WinSCP Check your time now! Always work case sensitive! $ apt-get install vim

Installation - Overview
IIS Shibboleth service Apache Shibboleth handler /Shibboleth.sso Shibboleth handler /Shibboleth.sso mod_auth mod_shib mod_ssl ... ISAPI filter Shibboleth RPC port 1600 Unix socket

RHEL webserver DocumentRoot: /var/www/html ($DOCROOT)
$ yum install httpd mod_ssl php DocumentRoot: /var/www/html ($DOCROOT) Configuration: /etc/httpd Logs: /var/log/httpd ($WEB_LOG) ServerName Start/Stop service $ vim /etc/httpd/conf/httpd.conf Line 265: ServerName $WORKSH_HOST $ service httpd start $ service httpd status httpd (pid ####) is running…

RHEL webserver Prepare test application $ mkdir /var/www/html/secure
$ vim /var/www/html/secure/index.php <?php header('Location: ?>

RHEL webserver - SSL $ vim /etc/httpd/conf.d/ssl.conf
SSLCertificateFile /etc/pki/$WORKSH_HOST.pem SSLCertificateKeyFile /etc/pki/$WORKSH_HOST.key SSLCertificateChainFile /etc/pki/terenasslchain.crt $ service httpd configtest $ service httpd restart $ openssl s_client –connect localhost:443

Debian webserver DocumentRoot: /var/www ($DOCROOT)
Configuration: /etc/apache2 Logs: /var/log/apache2 ($WEB_LOG) ServerName Start/Stop service $ apt-get install libapache2-mod-php5 $ vim /etc/apache2/sites-available/default $ vim /etc/apache2/sites-available/default-ssl Line 2, add: ServerName $WORKSH_HOST $ apache2ctl start $ apache2ctl status

Debian webserver Prepare test application $ mkdir /var/www/secure
$ vim /var/www/secure/index.php <?php header('Location: ?>

Debian webserver - SSL $ a2enmod ssl
$ vim /etc/apache2/sites-available/default-ssl SSLCertificateFile /etc/pki/$WORKSH_HOST.pem SSLCertificateKeyFile /etc/pki/$WORKSH_HOST.key SSLCertificateChainFile /etc/pki/terenasslchain.crt $ a2ensite default-ssl $ apache2ctl configtest $ /etc/init.d/apache2 restart $ openssl s_client –connect localhost:443

Windows Server 2008 - Apache
Download: : Win32 Binary including OpenSSL 0.9.8m (MSI Installer) DocumentRoot: c:\htdocs ($DOCROOT) Configuration: c:\Apache2.2 Logs: c:\Apache2.2\logs ($WEB_LOG) ServerName Start/Stop service using the Apache monitor in the tray C:\Apache2.2\conf\httpd.conf Line 171: ServerName $WORKSH_HOST

Windows Server 2008 - Apache
Prepare test application Create index.html file $ mkdir C:\htdocs\secure <html> <head> <title>redirect</title> <meta http-equiv="REFRESH" content="0;url=/Shibboleth.sso/Session"> </head> </html>

Windows Server 2008 – Apache - SSL
c:\Apache2.2\conf\httpd.conf Restart Apache2.2 via the tray LoadModule ssl_module modules/mod_ssl.so [..] Include conf/extra/httpd-ssl.conf #Include c:/opt/shibboleth-sp/etc/shibboleth/apache22.config c:\Apache2.2\conf\extra\httpd-ssl.conf SSLCertificateFile c:/pki/$WORKSH_HOST.pem SSLCertificateKeyFile c:/pki/$WORKSH_HOST.key SSLCertificateChainFile c:/pki/terenasslchain.crt $ openssl s_client –connect localhost:443

Windows Server 2008 - IIS IIS
Server Manager: Add Web Server (IIS) Role with ASP.NET ASP IIS 6 Management compatibility ISAPI filter ISAPI extensions IIS Management console IIS Management Scripts and Tools (Powershell) Documents: c:\inetpub\wwwroot\ ($DOCROOT) $ net start w3svc

Windows Server 2008 - IIS Prepare test application
Create Default.asp file $ mkdir C:\inetpub\wwwroot\secure <% Response.Redirect "/Shibboleth.sso/Session" %>

Windows Server 2008 – IIS - SSL
Import certificate Or use MMC Certificate snap-in $ certutil –p changeit –importpfx c:\pki\$WORKSH_HOST.p12 $ Get-ChildItem cert:\LocalMachine\My

Configure IIS Right click website  Edit bindings

Add.. Select SSL certificate Result

Shibboleth SP installation
$ cd /etc/yum.repos.d $ wget $ yum install shibboleth[.x86_64] (Accept GPG key 0x7D0A1B3D) Certificates Done by RPM after installation $ cp $PKI/sp-rh-N-cert.pem $SHIB_CONF/sp-cert.pem $ cp $PKI/sp-rh-N-key.pem $SHIB_CONF/sp-key.pem $ service shibd start /etc/httpd/conf.d/shib.conf /etc/rc.d/init.d/shibd

$ cd /etc/apt/sources.list.d/ $ vim lenny-backports.list deb lenny-backports main contrib non-free $ apt-get update $ apt-get install debian-backports-keyring $ apt-get -t lenny-backports install libapache2-mod-shib2 $ cp $PKI/sp-db-N-cert.pem $SHIB_CONF/sp-cert.pem $ cp $PKI/sp-db-N-key.pem $SHIB_CONF/sp-key.pem $ chown _shibd $SHIB_CONF/sp-key.pem

Configuration files provided by deb packages Create/etc/apache2/mods-available/shib2.conf /etc/apache2/mods-available/shib2.load /etc/init.d/shibd <Location /secure> AuthType shibboleth require shibboleth </Location> $ a2enmod shib2 $ /etc/init.d/shibd restart $ /etc/init.d/apache2 restart

Download MSI packet from Run shibboleth-sp win32.msi

After installation it is better to restart the OS Copy the self-signed keypair Restart Shibboleth service $ copy $PKI/sp-w8-N-cert.pem $SHIB_CONF/sp-cert.pem $ copy $PKI/sp-w8-N-key.pem $SHIB_CONF/sp-key.pem

Sanity checks Shibboleth ISAPI filter must be the first in the ‘ordered list’

Sanity checks Access Shibboleth handler from your browser Access session handler from your browser A valid session was not found. See how a Shibboleth error looks like

Bootstrapping the SP Goals: Working SP against a single IdP
Enable debugging of session attributes Avoid clock complaints

Bootstrapping the SP Choose your entityID https://$WORKSH_HOST
Should be: Unique Locally scoped Logical representative Unchanging Seen on the wire, configuration files, metadata, log files, etc

Bootstrapping the SP Relax some requirements, set your entityID and default IdP entityID $SHIB_CONF/shibboleth2.xml logger="syslog.logger" clockSkew=" "> <Host name=“$WORKSH_HOST“ redirectToSSL="443"> <ApplicationDefaults id="default" policyId="default" entityID=" <SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet" relayState="cookie" entityID=“ <Handler type="Session" Location="/Session" showAttributeValues="true"/>

Bootstrapping the SP Provide metadata remotely from test IdP $SHIB_CONF/shibboleth2.xml Backup at $SHIB_RUN Uncomment whole <MetadataProvider> Comment <MetadataFilter> Normally: Provide your SP’s metadata to IdP But, already done for you :-) Metadata self-generated by your Service Provider <MetadataProvider type="Chaining"> <MetadataProvider type="XML" uri=" backingFilePath="idp-metadata.xml" reloadInterval="3600"/>

Bootstrapping the SP For IIS:
Get site id (Run powershell as Administrator) Set correct site ID and name $ Import-Module WebAdministration $ dir IIS:\Sites <InProcess logger="native.logger"> <ISAPI normalizeRequest="true" safeHeaderNames="true"> <Site id="1" name=“$WORKSH_HOST"/>

Bootstrap the SP $SHIB_CONF/shibboleth2.xml (<RequestMap>)
<Host name=“$WORKSH_HOST" redirectToSSL="443"> <Path name="secure" authType="shibboleth" requireSession="true" >

Bootstrapping the SP – Quick test
Make sure configuration works Service Provider reloads shibboleth2.xml automatically when it changes Try it with a browser /secure/ is protected by shibboleth2.xml (<RequestMap>) Login with shibN / Get session information (you should see various attributes) $ shibd –tc $SHIB_CONF/shibboleth2.xml WIN$ shibd –check $SHIB_CONF/shibboleth2.xml

Bootstrapping SP - Logout
Local logout This won’t delete your session on the IdP! Close the browser in order to remove ALL your session cookies Or delete session cookies using the browser or an extension, e.g.: Firefox Web Developer extension

Bootstrapping SP – Discovery Service
Change the default SessionInitiator $SHIB_CONF/shibboleth2.xml Try again <SessionInitiator type="Chaining" Location="/Login" isDefault="false" id="Intranet" relayState="cookie" <SessionInitiator type="Chaining" Location="/DS" id="DS" relayState="cookie" isDefault="true"> […] <SessionInitiator type="SAMLDS" URL=" </SessionInitiator>

Configuration Basic configuration Attribute handling
Session Initiation Access control Adding a separate application Service provider handlers Session Initiators/Discovery

Basic configuration Goals:
Understand purpose and structure of SP configuration files Increase log level to DEBUG Configure metadata and add signature verification

Important directories
$SHIB_CONF Master and supporting configuration files Locally maintained metadata files HTML templates (customize them to adapt look&feel to your application) Logging configuration files (*.logger) Credentials (certificates and private keys) $SHIB_RUN UNIX socket Remotely fetched files (metadata, attribute-map) $SHIB_LOG shibd.log & transaction.log $WEB_LOG (written by Shibboleth module/ISAPI filter) native.log

Configuration files in $SHIB_CONF
shibboleth2.xml – main configuration file apache*.config – Apache module loading attribute-map.xml – attribute handling attribute-policy.xml – attribute filtering settings *.logger – logging configuration *Error.html – HTML templates for error messages localLogout.html – SP-only logout template globalLogout.html – single logout template Recommendation: Adapting *.html files to match the look & feel of the protected application improves user experience.

shibboleth2.xml structure
Outer elements of the shibboleth2.xml configuration file <OutOfProcess> / <InProcess> <UnixListener> / <TCPListener> <StorageService> <SessionCache> <ReplayCache> <ArtifactMap> <RequestMapper> Needed for session initiation and access control <ApplicationDefaults> Contains the most important settings of your SP <SecurityPolicies>

ApplicationDefaults structure
You are most likely to change something in here: <ApplicationDefaults> <Sessions> Defines handlers and how sessions are initiated and managed <Errors> Used to display error messages. Provide here logo, and CSS <RelyingParty> (*) To modify settings for certain IdPs/federations <MetadataProvider> Defines the metadata to be used by the SP <TrustEngine> Which mechanisms to use for signatures validation <AttributeExtractor> Attribute map file to use <AttributeResolver> Attribute resolver file to use <AttributeFilter> Attribute filter file to use <CredentialResolver> Defines certificate and private key to be use <ApplicationOverride> (*) Can override any of the above for certain applications

Logging First thing to do in case of problems
shibd.log and transaction.log written by shibd, native.log written by Shibboleth module/filter *.logger files contain predefined settings for output location and default logging level (INFO) along with useful categories to raise to DEBUG Log time is in UTC (~GMT)

Logging Raise categories To implement *.logger changed:
Try again $ vim $SHIB_CONF/shibd.logger log4j.rootCategory=DEBUG, shibd_log $ touch shibboleth2.xml $ tail –f /var/log/shibboleth/shibd.log

Metadata features Metadata describes the other components (IdPs) that the Service Provider can communicate with Four primary methods built-in: Local file (you manage it) Remote file (periodic refresh, local backup) Dynamic resolution of entityID (=URL) "Null" source that disables security (“OpenID” model) Security comes from metadata filtering, either by you or the SP: Signature verification White and blacklists

Signature verification
The Test IdPs metadata is signed. Until now, it was loaded without checking, which is not secure and not recommended! First, increase security: $SHIB_CONF/shibboleth2.xml Uncomment MetadataFilter for signature verification: <MetadataProvider type="XML” […] uri=“ <MetadataFilter type="Signature“ certificate="sp-cert.pem"/> </MetadataProvider>

Run … and in the output you will see: WARN OpenSAML.MetadataFilter.Signature [3]: filtering out group at root of instance after failed signature check: ERROR OpenSAML.Metadata.Chaining [3]: failure initializing MetadataProvider: SignatureMetadataFilter unable to verify signature at root of metadata instance. Metadata could not be loaded because it was signed with a different key (we “broke” the setup). So, let’s get the right key… $ shibd –tc $SHIB_CONF/shibboleth2.xml WIN$ shibd –check $SHIB_CONF\shibboleth2.xml

Get certificate from IdP: Then fix it: $SHIB_CONF/shibboleth2.xml Run again $ cd $SHIB_CONF $ wget <MetadataProvider type="XML” […] > <MetadataFilter type="Signature“ certificate=“worksh-idp.cc.kuleuven.be.pem"/> </MetadataProvider> $ shibd –tc $SHIB_CONF/shibboleth2.xml WIN$ shibd –check $SHIB_CONF\shibboleth2.xml

Attribute handling Goals: Understand how attributes are transported
Learn how attributes are mapped and filtered See how attributes can be used as identifiers Add an attribute mapping and filtering rule

SP attribute terminology
Push Delivering attributes with SSO assertion via web browser Pull Querying for attributes after SSO via back-channel (SP -> IdP) Extraction Decoding SAML information into neutral data structures mapped to environment or header variables Filtering Blocking invalid, unexpected, or unauthorized values based on application or community criteria Resolution Resolving a SSO assertion into a set of additional attributes (e.g. queries)

Scoped attributes Common term for attributes that consist of a relation between a value and a scope, usually an organizational domain name E.g. affiliation = Makes values globally usable or unique Lots of special treatment in Shibboleth to make them more useful and "safe" Alternatively, split value and scope into separate attributes: affiliation=“student” and homeOrganization=“kuleuven.be”

Attribute mappings SAML attributes from any source are "extracted" using the configuration rules in /etc/shibboleth/attribute-map.xml Each element is a rule for decoding a SAML attribute and assigning it a local id which becomes its mapped variable name Attributes can have one or more id and multiple attributes can be mapped to the same id The id can also be used as header name in the webserver for this attribute

Dissecting an Advanced Attribute Rule
<Attribute id="affiliation" aliases="aff affil" name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"> <AttributeDecoder xsi:type="ScopedAttributeDecoder" caseSensitive="false"/> </Attribute> id The primary "id" to map into, also used in web server environment aliases Optional alternate names to map into name SAML attribute name or NameID format to map from AttributeDecoder xsi:type Decoder plugin to use (defaults to simple/string) caseSensitive How to compare values at runtime (defaults to true)

Adding attribute mappings
Add first and lastname SAML 2 attribute mappings: $SHIB_CONF/attribute-map.xml After saving, changes take effect immediately but NOT for any existing sessions Therefore, restart your browser (or delete your session cookies) and continue on next slide … <Attribute name="urn:oid: " id="sn” aliases=“surname”/> name="urn:oid: " id="givenName"/>

K.U.Leuven attribute mappings
Attribute-map made compatible with 1.3 naming conventions $SHIB_CONF/shibboleth2.xml <!– <AttributeExtractor type="XML" validate="true" path="attribute-map.xml"/> --> <AttributeExtractor type="XML" uri=" backingFilePath="attribute-map.xml" reloadInterval="7200"/>

Common identifiers Local userid/netid/uid (“intranet userid”), e.g. “u ” Usually readable, persistent but not permanent, often reassigned, not unique address, e.g. Usually readable, persistent but not permanent, often reassigned, unique eduPersonPrincipalName, e.g. Usually readable, persistent but not permanent, can be reassigned, unique eduPersonTargetedID / SAML 2.0 persistent ID Not readable, semi-permanent, not reassigned, unique

Common identifiers Legacy attribute placeholder for the SAML 2.0 persistent NameID format: opaque pairwise (IdP/SP) original motivation was privacy, but strongest features are lack of reassignment and immunity to name changes In web server environment, persistentId= <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier=" SPNameQualifier=" stringupto256chars </saml:NameID>

REMOTE_USER Special single-valued variable that all web applications should support for container-managed authentication of a unique user. Any attribute, once extracted/mapped, can be copied to REMOTE_USER Multiple attributes can be examined in order of preference, but only the first value will be used. IIS doesn’t support to set the REMOTE_USER

Changing REMOTE_USER In case your application needs to have a remote user for authentication, you just could make Shibboleth put an attribute (e.g. ”sn”) as REMOTE_USER: $SHIB_CONF/shibboleth2.xml REMOTE_USER=”sn eppn persistent-id targeted-id" If sn attribute is available, it will be put into REMOTE_USER Attribute sn has precedence over eppn in this case This allows very easy “shibbolization” of some web applications

Attribute filtering Answers the "who can say what" question on behalf of an application Service Provider can make sure that only allowed attributes and values are made available to application Some examples: constraining the possible values or value ranges of an attribute (e.g. eduPersonAffiliation, telephoneNumber, ....) limiting the scopes/domains an IdP can speak for (e.g. university x cannot assert limiting custom attributes to particular sources

Default filter policy As default, attributes are filtered out unless there is a rule! Shared rule for legal affiliation values Shared rule for scoped attributes Generic policy applying those rules and letting all other attributes through. Check $SHIB_LOG/shibd.log for signs of filtering in case of problems with attributes not being available. You would find something like “no rule found, removing all values of attribute (#attribute name#)“

Session initiation Goals: Learn how to initiate a Shibboleth session
Understand their advantages and disadvantages Know where to require a session, what to protect

Content protection and session initiation
Before access control (will be covered later on) can occur, a Shibboleth session must be initiated Session initiation and content protection go hand in hand Requiring a session means the user has to authenticate Only authenticated users can access protected content

Content protection settings
Protect hosts, directories, files or queries Apache .htaccess (dynamic) or httpd.conf (static) Apache / IIS / other RequestMap Requires Shibboleth to know exact hostname Very powerful and flexible thanks to boolean/regex operations Try accessing You should get access because the directory is not protected

Content protection with .htaccess
Prepare webserver (<Directory name=“$DOCROOT”>) Let’s protect the directory by requiring a Shibboleth session: Synonym for the last line (used in Shibboleth 1.3): ShibRequireSession On AllowOverride AuthConfig $ mkdir $DOCROOT/secure2 $ vim $DOCROOT/secure2/.htaccess AuthType shibboleth require shibboleth ShibRequestSetting requireSession 1

Test content protection rule
Clear session and then access Authentication is enforced and access should be granted By now, all authenticated users get access Content protection with authorization will be covered later

Content protection with RequestMap
$ vim $DOCROOT/secure2/.htaccess $SHIB_CONF/shibboleth2.xml Module (mod_shib or ISAPI filter) provides request URL to shibd to process it Clearing session and then accessing /secure2/ now, one also is forced to authenticate AuthType shibboleth require shibboleth <Host name=“$WORKSH_HOST” redirectToSSL=“443”> <Path name=“secure2” authType=“shibboleth” requireSession=“true”/> </Host>

RequestMap “Fragility”
By default, Apache "trusts" the user’s web browser about what the requested hostname is and reports that value internally To illustrate the problem, try accessing this URL: Script can be accessed unprotected/without a session… ? How to fix? Make Apache use configured ServerName httpd.conf IIS: normalizeRequest UseCanonicalName On

Other content settings
Requesting types of authentication E.g enforce X.509 user certificate authentication Redirect to SSL Custom error handling pages to use Redirection-based error handling In case of an error, redirect user to custom error web page with error message/type as GET arguments forceAuthn Disable Single-Sign on and force a re-authentication isPassive Check whether a user has an SSO session and if he has, automatically create a session on SP without any user interaction Supplying a specific IdP to use for authentication

Lazy Sessions The mode of operation so far prevents an application from running without a login. Two other very common cases: Public and private access to the same resources Separation of application and SP session Semantics are: if valid session exists process it as usual (attributes in environment array, REMOTE_USER, etc.) But if a session does NOT exist or is invalid, ignore it and pass on control to webserver/scripts

Lazy Sessions example Construct URL ?target= Shibboleth handler: Session Initiator: /Login Target location: ?target= Other options: Most parameters can come from three places, in order of precedence: Query string parameter to Shibboleth handler A content setting (Webserver config or RequestMap) <SessionInitiator> element

Lazy Sessions example IIS: RequestMap entry for secure3
$ vim $DOCROOT/secure3/.htaccess IIS: RequestMap entry for secure3 Save PHP/ASP script from worksh-idp.cc.kuleuven.be: /home/shib/ShibbolethSPWorkshop/examples/lazy_session.[php|asp] at $DOCROOT/secure3/lazy_session.[php|asp] Access AuthType shibboleth require shibboleth

Where to require a Shibboleth session
Whole application with “required” Shibboleth session Easiest way to protect a set of documents No other authentication methods possible like this Whole application with “lazy” Shibboleth session Also allows for other authentication methods Authorization can only be done in application Only page that sets up application session Well-suited for dual login Application can control session time-out Generally the best solution

Access control Goals: Create some simple access control rules
Get an overview about the three ways to authorize users Understand their advantages and disadvantages

Access control Two implementations are provided by the SP:
.htaccess "require" rule processing XML-based policy syntax attached to content via RequestMap Third option: Integrate access control into webapplication

Access control + - 1.a httpd.conf 1.b .htaccess 2. XML AccessControl
3. Application Access Control Easy to configure Can also protect locations or virtual files URL Regex Dynamic Platform independent Powerful boolean rules Very flexible and powerful with arbitrarily complex rules URL Regex Support Only works for Apache Not dynamic Very limited rules Only usable with “real” files and directories XML editing Configuration error can prevent SP from restarting You have to implement it yourself You have to maintain it yourself + -

1. Apache httpd.conf or .htaccess
Work almost like known Apache “require” rules Special rules: shibboleth (no authorization) valid-user (require a session, but NOT identity) user (REMOTE_USER as usual) group (group files as usual) authnContextClassRef, authnContextDeclRef Default is boolean "OR”, use ShibRequireAll for AND rule Regular expressions supported using special syntax: require affiliation staff require sn bar require mail ~

Side note: Aliases If in the attribute-map.xml file, there is a definition like: This allows using rules aliases in authorization rules, e.g.: Aliases can also be used in RequestMap <Attribute name="urn:mace:dir:attribute-def:eduPersonAffiliation" id="Shib-EP-Affiliation" aliases="affiliation aff affil"> […]/> require affiliation staff #instead of require Shib-EP-Affiliation staff

1. Example .htaccess file Require a user to be staff member $DOCROOT/staff-only/.htaccess Access with user “staff”, access should be granted Try the same with “shibN” user, access should be denied AuthType Shibboleth ShibRequestSetting requireSession 1 require unscoped-affiliation staff

1. Advanced .htaccess file
Require a user to be a student or to have an entitlement: Access: with user “student” and “staff”, access should be granted. Try again with “shibN”, access should be denied. $ mkdir $DOCROOT/toledo $ vim $DOCROOT/toledo/.htaccess AuthType Shibboleth ShibRequestSetting requireSession 1 require unscoped-affiliation student require entitlement ~ .*toledo.*

2. XML access control Can be used for access control independent from web server and operating system XML Access control rules can be embedded inside RequestMap or can also be dynamically loaded from external file. WARNING: Can bring down entire webserver Same special rules as .htaccess, adds boolean operators (AND,OR,NOT)

2. XML access control example
Same as previous example but now with XML access control embedded in RequestMap $ vim $DOCROOT/toledo/.htaccess AuthType Shibboleth require shibboleth $ vim $SHIB_CONF/shibboleth2.xml <Host name=“$WORKSH_HOST"> [..] <Path name=“toledo" authType="shibboleth" requireSession="true"> <AccessControl> <OR> <RuleRegex require="entitlement">.*toledo.*</RuleRegex> <Rule require="unscoped-affiliation">student</Rule> </OR> </AccessControl> </Path> </Host>

3. Application managed access control
Application can access and use Shibboleth attributes by reading them from the web server environment Attributes then can be used for authentication/access control/authorization #PHP: if ($_SERVER[‘affiliation’] == ‘staff’) { grantAccess() } #Perl: if ($ENV{‘affiliation’} == ‘staff’) { &grantAccess() } #ASP: if (Request.ServerVariables(‘affiliation’) == ‘staff’ ){

3. Application managed access control
Default is to use environment variables instead of HTTP headers (Apache) Cannot be manipulated in any way from outside Unfortunately not all webservers support a mechanism to create custom variables within webserver (IIS,Sun/iPlanet) Solution: AuthType shibboleth ShibRequestSetting requireSession 1 require shibboleth ShibUseHeaders On

Adding a separate (Shibboleth) application
Goals: Define another application Protect new application Know how to configure them if necessary

Terminology Service Provider (physical)
An installation of the software on a server Service Provider/”Resource” (logical) Web resources viewed externally as a unit Each entityID identifies exactly one logical SP SP Application Web resources viewed internally as a unit Each applicationId identifies exactly one logical application A user session is bound to exactly one application

Virtualization concepts
A single physical SP can host any number of logical SPs A logical SP can then include any number of "applications" Web virtual hosting is often related but is also independent Applications can inherit or override default configuration settings on a piecemeal basis Multiple physical SPs can also act as a single logical SP Clustering for load balancing and failover

Adding an application Goal: Add a second application with a different entityID living in its own virtual host $SHIB_CONF/shibboleth2.xml <RequestMap applicationId="default"> <Host name=“$IP” applicationId="alt"/> [..] <ApplicationOverride id="alt" entityID=" </ApplicationDefaults>

Adding an application For the additional application, canonical names should be turned off again (unless you use Vhosts) httpd.conf Test application: The IdP will throw an ERROR (entityID is not trusted) Error Message: SAML 2 SSO profile is not configured for relying party ' Check logging $SHIB_LOG/shibd.log and $WEB_LOG/native.log (DEBUG) You should see the new entityID UseCanonicalName Off

Adding an application <ApplicationOverride> Rule of thumb is that any settings you don't override inside the element will be inherited from the <ApplicationDefaults> element that surrounds the override . Limitations: You have to supply all the settings needed in the <Sessions> element because of the need to override the handlerURL. You do NOT have to redefine all of the handler child elements. The handlerURL MUST be unique for each SP and MUST map to the same applicationId Respect the XML sequence!

Clustering Configure multiple physical installations to share an entityID, and possibly credentials Configuration files often can be identical across servers that share an external hostname Session management: SP itself now clusterable via ODBC or memcached Host shibboleth service on one system

Service provider handlers
Goals: Understand the idea of a handler Get an overview about the different types of handlers Know how to configure them if necessary

SP handlers "Virtual" applications inside the SP with API access:
SessionInitiator (requests) E.g. /Shibboleth.sso/Login AssertionConsumerService (incoming SAML response) E.g. /Shibboleth.sso/SAML/POST LogoutInitiator (SP signout) E.g. /Shibboleth.sso/Logout SingleLogoutService (incoming SLO) ManageNameIDService (advanced SAML) ArtifactResolutionService (advanced SAML) Generic (diagnostics, other useful features) E.g. /Shibboleth.sso/Session /Shibboleth.sso/Status /Shibboleth.sso/Metadata

SP handlers The URL of a handler = handlerURL + the Location of the handler. e.g. for a virtual host testsp.example.org with handlerURL of "/Shibboleth.sso", a handler with a Location of "/Login" will be Handlers aren’t always SSL-only, but usually should be (handlerSSL="true"). Metadata basically consists of entityID, keys and handlers Handlers are never "protected" by the SP But sometimes by IP address (e.g. with acl=“ ”)

Session initiators/Discovery
Goals: Understand the concepts of discovery/session initiation Chains and protocol precedence Overview about various discovery mechanisms

Session initiators / Discovery concepts
Session initiator Handler that created a SAML authN request for an IdP or uses a discovery mechanism to identify the IdP Discovery (in Shibboleth) Identifying the IdP of a particular user WAYF service Old name in Shibboleth for a particular way to do discovery Handler chain Sequence of handlers that share configuration and run consecutively until “something useful happen” or an error occurs

Intranet case Single IdP, multiple protocols, no discovery:
Protocol precedence controlled by order of SessionInitiators within a chain Common properties defined at the top are inherited by SessionInitiators in chain <SessionInitiator type="Chaining" Location="/Login" id="Intranet" isDefault="true" relayState="cookie" entityID="urn:mace:kuleuven.be:kulassoc:kuleuven.be"> <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/> <SessionInitiator type="Shib1" defaultACSIndex="5"/> </SessionInitiator>

Change protocol precedence
Example: switch order of chain Still allows either protocol, but if the IdP supports Shibboleth profile of SAML1, it will be preferred <SessionInitiator type="Chaining" Location="/Login" id="Intranet" isDefault="true" relayState="cookie" entityID="urn:mace:kuleuven.be:kulassoc:kuleuven.be"> <SessionInitiator type="Shib1" defaultACSIndex="5"/> <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/> </SessionInitiator>

Identity provider discovery
Protocol SessionInitiators work when the IdP is known For consistency, discovery is implemented with alternate SessionInitiators that operate only when the IdP is NOT known A typical federated chain includes one or more "protocol" handlers followed by a single "discovery" handler at the end, like a safety net

Typical discovery methods
External options: Older WAYF model, specific to Shibboleth/SAML1, SP loses control if a problem occurs Newer SAMLDS model, recently standardized, supports multiple SSO protocols and allows the SP to control the process Internal options: Implemented by an application (e.g. Toledo) Followed by a redirect with the entityID: /Shibboleth.sso/Login?entityID=urn:mace:kuleuven.be:kulassoc:kuleuven.be Advanced "Cookie", "Form", and "Transform" SessionInitiators

Discovery service case (default)
Multiple protocols, discovery via DS: Same as intranet case, but omits entityID and adds the safety net at the bottom Last SessionInitiator in chain tells the DS to return the user to this location with a lazy session redirect that will invoke an earlier handler (SAML2 or Shib1) in the chain <SessionInitiator type="Chaining" Location="/DS" id=“DS" isDefault="true" relayState="cookie”> <SessionInitiator type="SAML2" defaultACSIndex="1" template="bindingTemplate.html"/> <SessionInitiator type="Shib1" defaultACSIndex="5"/> <SessionInitiator type="SAMLDS" URL=" </SessionInitiator>

External discovery/WAYF
Easy to use Choice can be cached in cookie DS displays only applicable IdPs Loss of control, UI fidelity Impact of errors List of IdPs can become very long + -

Conclusions Introduction: “What is Shibboleth?”

Shibboleth Service Provider Workshop

Similar presentations

Presentation on theme: "Shibboleth Service Provider Workshop"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Shibboleth Service Provider Workshop

Similar presentations

Presentation on theme: "Shibboleth Service Provider Workshop"— Presentation transcript:

Similar presentations

About project

Feedback