Howto: Create a virtual platform Shibboleth



Similar documents
Implementing HTTPS in CONTENTdm 6 September 5, 2012

Running Multiple Shibboleth IdP Instances on a Single Host

Installing an SSL certificate on the InfoVaultz Cloud Appliance

This section describes how to use SSL Certificates with SOA Gateway running on Linux.

To enable https for appliance

Shibboleth Identity Provider (IdP) Sebastian Rieger

GlobalSign Enterprise Solutions Google Apps Authentication User Guide

User s guide. APACHE SSL Linux. Using non-qualified certificates with APACHE SSL Linux. version 1.3 UNIZETO TECHNOLOGIES S.A.

Installing Dspace 1.8 on Ubuntu 12.04

Apache2 Configuration under Debian GNU/Linux. Apache2 Configuration under Debian GNU/Linux

Shibboleth SP Simple Installation Guide For LINUX

DoD Public Key Enablement (PKE) Quick Reference Guide. Securing Apache HTTP with mod_ssl for Linux

Real Vision Software, Inc.

Installing Apache Software

ViMP 3.0. SSL Configuration in Apache 2.2. Author: ViMP GmbH

HP ALM. Software Version: External Authentication Configuration Guide

SecuritySpy Setting Up SecuritySpy Over SSL

Federating with Web Applications

WEB2CS INSTALLATION GUIDE

Configuring Ubuntu Server as a Firewall and Reverse Proxy for OWA 2007 Configuration Guide

CERTIFICATE-BASED SINGLE SIGN-ON FOR EMC MY DOCUMENTUM FOR MICROSOFT OUTLOOK USING CA SITEMINDER

Enterprise SSL Support

Setting Up CAS with Ofbiz 5

How to: Install an SSL certificate

Federation of OpenStack clouds

Shibboleth SP Hands-on. Shilen Patel - shilen@duke.edu Rob Carter - rob@duke.edu Gonzalo Guzman - gonz@mcnc.org

Laboratory Exercises VI: SSL/TLS - Configuring Apache Server

Shibboleth SP Simple Installation Guide For Windows and IIS

The GOV.UK Verify onboarding process

esync - Receiving data over HTTPS

How-to-Guide: Apache as Reverse Proxy for Fiori Applications

Integrating Apache Web Server with Tomcat Application Server

GlobalSign Solutions

24x7 Scheduler Multi-platform Edition 5.2

How to setup HTTP & HTTPS Load balancer for Mediator

Crawl Proxy Installation and Configuration Guide

itixi Ubuntu Server Deployment How-To/Information

ShibboLEAP Project. Final Report: School of Oriental and African Studies (SOAS) Colin Rennie

EQUELLA. Clustering Configuration Guide. Version 6.2

VMware Identity Manager Connector Installation and Configuration

Parallels Panel. Administrator's Guide to Configuring Apache on Servers Running Parallels Plesk Panel 10. Revision 1.0

Apache HTTP Server. Implementation Guide. (Version 5.7) Copyright 2013 Deepnet Security Limited

Securing Web Access with a Private Certificate Authority

Computer Services Documentation

UNICORE GATEWAY. UNICORE Team. Document Version: Component Version: Date: 19 Apr 2011

DEPLOYMENT GUIDE Version 1.0. Deploying the BIG-IP LTM with Apache Tomcat and Apache HTTP Server

Integration Guide. SafeNet Authentication Service. Oracle Secure Desktop Using SAS RADIUS OTP Authentication

UNICORE GATEWAY. UNICORE Team. Document Version: Component Version: Date:

ITRAINONLINE MMTK LINUX BASED INFRASTRUCTURE HANDOUT

Pexip Infinity Reverse Proxy Deployment Guide

Host your websites. The process to host a single website is different from having multiple sites.

unigui Developer's Manual 2014 FMSoft Co. Ltd.

Security Workshop. Apache + SSL exercises in Ubuntu. 1 Install apache2 and enable SSL 2. 2 Generate a Local Certificate 2

Redmine Installation on Debian. v1.1

StreamServe Persuasion SP5 StreamStudio

Apache and Virtual Hosts Exercises

Web Application Firewall

APACHE HTTP SERVER 2.2.8

Setting up an Apache Web Server for Greenstone 2 Walkthrough

Systems Integration On Free Software

ENABLING RPC OVER HTTPS CONNECTIONS TO M-FILES SERVER

Installing Apache as an HTTP Proxy to the local port of the Secure Agent s Process Server

HOWTO. Configure Nginx for SSL with DoD CAC Authentication on CentOS 6.3. Joshua Penton Geocent, LLC

HOW TO BUILD A VMWARE APPLIANCE: A CASE STUDY

SOLR INSTALLATION & CONFIGURATION GUIDE FOR USE IN THE NTER SYSTEM

Technical specification

Tonido Cloud Admin Guide

CentraSite SSO with Trusted Reverse Proxy

Integrating VMware Horizon Workspace and VMware Horizon View TECHNICAL WHITE PAPER

Enabling Kerberos SSO in IBM Cognos Express on Windows Server 2008

A STEP- BY-STEP GUIDE


Creating X.509 Certificates With OpenSSL

SVNManager Installation. Documentation. Department of Public Health Erasmus MC University Medical Center

Tenrox. Single Sign-On (SSO) Setup Guide. January, Tenrox. All rights reserved.

The course will be run on a Linux platform, but it is suitable for all UNIX based deployments.


CN=Monitor Installation and Configuration v2.0

Greenstone Documentation

Step-by-Step guide to setup an IBM WebSphere Portal and IBM Web Content Manager V8.5 Cluster From Zero to Hero (Part 2.)

FERMILAB CENTRAL WEB HOSTING SINGLE SIGN ON (SSO) ON CWS LINUX WITH SAML AND MOD_AUTH_MELLON

Shibboleth Configuration in Tübingen

Administering mod_jk. To Enable mod_jk

Web Server: Principles and Configuration Web Programming 8) Web Server

Ciphermail Gateway Separate Front-end and Back-end Configuration Guide

mod_auth_pubtkt a pragmatic Web Single Sign-On solution by Manuel Kasper, Monzoon Networks AG mkasper@monzoon.net

Implementing a Weblogic Architecture with High Availability

BlackBerry Enterprise Service 10. Version: Configuration Guide

Authentication Methods

How-to-Guide: Reverse Proxy and Load Balancing for SAP Mobile Platform 3.X

Setup Guide Access Manager 3.2 SP3

INSTALLATION GUIDE VERSION

ArpViewer Manual Version Datum

OIOSAML 2.0 Toolkits Test results May 2009

How to Install Multicraft on a VPS or Dedicated Server (Ubuntu bit)

Configuring Single Sign-On for Documentum Applications with RSA Access Manager Product Suite. Abstract

CA Performance Center

Apache 2 mod_ssl by example

Table of Contents GEEK GUIDE APACHE WEB SERVERS AND SSL AUTHENTICATION

Installing Virtual Coordinator (VC) in Linux Systems that use RPM (Red Hat, Fedora, CentOS) Document # 15807A1-103 Date: Aug 06, 2012

Transcription:

CAROUX Félicien NEMPONT Maxime Promotion FI-2010 Howto: Create a virtual platform Shibboleth Scientific & IT Project 2009-2010 Supervisor: M. LANDRU Jacques (Telecom Lille 1) M. SAGNIMORTE Thomas (Oxylane)

Table of contents 1. Create the work environment... 1 1.1. Build a Debian image... 1 1.2. Run this image to install main packets... 1 1.3. Java s installation... 1 1.4. Apache s installation... 1 1.5. SSH s installation... 1 1.6. Create 2 images... 2 2. IDP s installation & basic configurations... 2 2.1. Run the IDP image... 2 2.2. Tomcat s installation... 2 2.3. Shibboleth s installation... 2 2.4. Tomcat s configuration... 3 2.5. Apache s configuration... 3 2.6. First tests... 5 3. SP s installation... 6 3.1. Run the SP image... 6 3.2. Shibboleth s installation... 6 4. Our virtual topology... 6 4.1. IDP s configuration with our virtual topology... 7 4.2. SP s configuration with our virtual topology... 8 5. Final tests... 10 6. Bibliography... 1 7. Apendix... 2 IDP: httpd.conf... 2 IDP: logging.xml... 3 IDP: ports.conf... 6 IDP: relying-party.xml... 7 IDP: ssl8443... 13 IDP s metadata... 17 SP: httpd.conf... 19 SP: ports.conf... 21 SP: shibboleth2.xml... 22 SP: shibd.logger... 28 SP: SP.crt... 29 SP: SP.key... 30 SP s metadata... 31

1. Create the work environment 1.1. Build a Debian image #qemu -img create vmain.raw 5G #kvm -hda vmain.raw -cdrom/home/user/desktop/debian-5-03-i386-netinst.iso -boot d -m 1024 1.2. Run this image to install main packets #kvm -hda vmain.raw -m 512 -name main 1.3. Java s installation First, we must install the non-free repository. Edit the sources.list to add the keyword nonfree after this sentence: deb http://ftp.fr/debian / lenny main #nano /etc/apt/sources.list deb http://ftp.fr/debian / lenny main non-free After that, we can update the aptitude package and begin the Java s installation. #aptitude update #aptitude install sun-java6-jre sun-java6-jdk It s necessary to fix a JAVA_HOME variable environment. To do this, add the following line export JAVA_HOME=/usr/lib/jvm/java-6-sun/ in /home/user/.bashrc. #nano /home/user/.bashrc export JAVA_HOME=/usr/lib/jvm/java-6-sun/ 1.4. Apache s installation In a Shibboleth configuration, Apache manages SSL and the certificates. Use the following command to install Apache. #aptitude install apache2 1.5. SSH s installation We use SSH to transfer files (like metadata) between the virtual machines. Use the following command to install SSH. CAROUX Félicien NEMPONT Maxime Page 1

#aptitude install ssh 1.6. Create 2 images In our topology, we use 2 virtual images, one for each kind of server (IDP & SP). These 2 virtual images are in a qcow2 format (write-only). They take information from a mother image (vmain.raw). vmain.raw is in read-only. #kvm-img create -b vmain.raw -f qcow2 IDP #kvm-img create -b vmain.raw -f qcow2 SP 2. IDP s installation & basic configurations 2.1. Run the IDP image #kvm -hda -IDP -m 512 -name IDP 2.2. Tomcat s installation In a Shibboleth configuration, Tomcat manages the IDP stack. First, download the core file here: http://tomcat.apache.org/download-55.cgi After that use the following commands to install correctly Tomcat. #tar xzf apache-tomcat-5.5.28.tar.gz #mv apache-tomcat-5.5.28 /usr/local/tomcat #adduser tomcat #chown -R tomcat /usr/local/tomcat It s necessary to fix a CATALINA_HOME. To do this, add the following line export CATALINA_HOME=/usr/local/tomcat in /home/user/.bashrc. #nano /home/user/.bashrc export CATALINA_HOME=/usr/local/tomcat 2.3. Shibboleth s installation First, download the shibboleth s file for the IDP here: http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/ Unzip the downloaded file. Then, in this folder, run the script install.sh to install the shibboleth stack. #unzip shibboleth-identityprovider-2.1.5-bin.zip #sh install.sh CAROUX Félicien NEMPONT Maxime Page 2

In our configuration, the path install was /usr/local/idp and the hostname was the private IP address of our IDP(The IP address that we will fix after). 2.4. Tomcat s configuration We copy libraries used for the servlet Java IDP to work in the Tomcat s librairies folder. #cp /home/user/desktop/shibboleth-identityprovider-2.1.5/endorsed/* /usr/local/tomcat/common/endorsed/ Add request.tomcatauthentication="false" and Address="127.0.0.1" to Tomcat's /usr/local/tomcat/conf/server.xml port 8009 AJP13 connector so Apache can relay usernames to the IdP. #nano /usr/local/tomcat/conf/server.xml <Connector port="8009" enablelookups="false" redirectport="8443" protocol="ajp/1.3" request.tomcatauthentication="false" address="127.0.0.1" /> Thanks to a browser, we can use a graphical user interface to manage the modules of Tomcat (Management link in the web interface). But first, we must edit the following file: #nano /usr/local/tomcat/conf/tomcat-users.xml. <tomcat-users> <role rolename="manager"/> <user username="tomcat" password="tomcat" roles= tomcat,manager /> Now, we create a XML file used for deploy automatically the IDP stack without copy out the archive.war in the folder webapps/ of Tomcat. This method avoids cashing problems wrongly managed by Tomcat. #nano /usr/local/tomcat/conf/catalina/localhost/idp.xml <Context docbase="/opt/shibboleth-idp/war/idp.war" privileged="true" antiresourcelocking="false" antijarlocking="false" unpackwar="false" /> 2.5. Apache s configuration Then, we create a test user using the htpasswd command. #htpasswd -c /usr/local/idp/credentials/user.db NameUser CAROUX Félicien NEMPONT Maxime Page 3

After that, define the following in /etc/apache2/httpd.conf to front-end your IDP with basic authentication. #nano /etc/apache2/httpd.conf <Location /idp/authn/remoteuser> AuthType Basic AuthName "Our IDP" AuthUserFile /usr/local/idp/credentials/user.db require valid-user </Location> Add the following line to httpd.conf to pass requests for the IDP into Tomcat: #nano /etc/apache2/httpd.conf ProxyPass /idp/ ajp:// 127.0.0.1:8009/idp/ ProxyPass /jsp-examples/ ajp://127.0.0.1:8009/jsp-examples/ Apache manages SSL and the certificates. To configure that, edit the /etc/apache2/httpd.conf. In our configuration, we use the following options: #nano /etc/apache2/httpd.conf SSLCertificate /usr/local/idp/credentials/idp.crt SSLCertificateKeyFile /usr/local/idp/credentials/idp.key SSLVerifyClient optional_no_ca SSLVerifyDepth 10 To resolve some permission issues, edit /etc/apache2/mods-available/proxy.conf and comment the line Deny from all. #nano /etc/apache2/mods-available/proxy.conf #Deny from all To work in our configuration, Apache needs some modules. Enable these mods with the following commands. /etc/apache2/mods-available# a2enmod proxy /etc/apache2/mods-available# a2enmod proxy_ajp /etc/apache2/mods-available# a2enmod ssl CAROUX Félicien NEMPONT Maxime Page 4

You can check if the mods are correctly enabled. To do this, check if you see the mods in /etc/apache2/mods-enabled After that, copy /etc/apache2/sites-available/default-ssl and change the listening port (in the new file, from 443 to 8443). We have already set the SSLCertificate, so don t forget to comment all SSLCertificate in this file. #cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/ssl8443 #nano /etc/apache2/sites-available/ssl8443 <Virtualhost _default_ :8443> #SSLCertificateFile #SSLCertificateKeyFile Edit too the following file to change the value of the listening port. #nano /etc/apache2/ports.conf Listen 8443 Enable the configured site. /etc/apache2/mods-available#a2ensite default-ssl /etc/apache2/mods-available#a2ensite ssl8443 2.6. First tests Restart Apache and start Tomcat thanks to the following commands. #/etc/init.d/apache2 restart /usr/local/tomcat/bin# su tomcat -c sh startup.sh Thanks to a browser, you can test Tomcat (if it s work) with this link : http://127.0.0.1:8080/ You can manage the different stack (like IDP) with the tomcat manager link. For example, you can check with the tomcat manager link (and with the user created before) if the IDP works. The following link http://127.0.0.1:8080/idp/profile/status can confirm (Warning: Shibboleth s links are Case sensitive). You can test too the ports redirection. To do this, consult the page http://127.0.0.1/jspexamples/ instead of http://127.0.0.1:8080/jsp-examples/. CAROUX Félicien NEMPONT Maxime Page 5

3. SP s installation 3.1. Run the SP image #kvm -hda -SP -m 512 -name SP 3.2. Shibboleth s installation #aptitude install libapache2-mod-shib2 4. Our virtual topology To create this virtual topology, we use the Brctl method (Ethernet bridge). To do this, we must configure the host machine and the 2 virtual machines as follow: Host machine : #nano /etc/network/interfaces # The loopback network interface auto lo eth0 br0 iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp iface br0 inet static pre-up brctl addbr br0 address 192.168.0.254 netmask 255.255.255.0 broadcast 192.168.0.255 CAROUX Félicien NEMPONT Maxime Page 6

Virtual machine (IDP): #nano /etc/network/interfaces # The loopback network interface auto lo eth0 iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp iface br0 inet static address 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.254 Use the following command to restart the network configuration on each machine. #/etc/init.d/networking/ restart 4.1. IDP s configuration with our virtual topology First launch the IDP with the following command #kvm -hda IDP -m 512 -name IDP -net nic,macaddr=de:ad:be:ef:85:26 -net tap In our topology, Shibboleth runs in a push-method To configure this method, edit /usr/local/idp/conf/relying-party.xml and change the values of signresponses and signassertions. #nano /usr/local/idp/conf/relying-party.xml <ProfileConfiguration xsi:type="saml:shibbolethssoprofile" includeattributestatement="false" assertionlifetime="300000" signresponses="always" signassertions="always" /> CAROUX Félicien NEMPONT Maxime Page 7

To work, Shibboleth needs metadata. We configure the IDP to find the SP s metadata. We consider for the moment that the SP s metadata are on the IDP s Desktop. Add the following configuration in /usr/local/idp/conf/relying-party.xml. #nano /usr/local/idp/conf/relying-party.xml <MetadataProvider xsi:type="filesystemmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata" id="mymetadata" metadatafile="/home/user/desktop/spmetadata"> Generate the IDP s metadata thanks to the following link and save it for example in the Desktop: http://127.0.0.1/idp/profile/metadata/saml Run the SP image as follow: #kvm -hda SP -m 512 -name SP -net nic,macaddr=de:ad:be:ef:21:60 -net tap Then, use SSH on IDP to transfer the metadata #scp /home/user/desktop/saml 192.168.0.2:/home/user/Desktop/IdpMetadata 4.2. SP s configuration with our virtual topology First, configure Apache to create one secured location by shibboleth. #nano /etc/apache2/httpd.conf <IfModule mod_alias.c> <Location /shibboleth-sp> Allow from all </Location> Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css Alias /shibboleth-sp/logo.jpg /usr/share/shibboleth/logo.jpg </IfModule> SSLCertificateFile /etc/shibboleth/sp.crt SSLCertificateKeyFile /etc/shibboleth/sp.key SSLVerifyClient optional_no_ca SSLverifyDepth 10 <Location /secure> AuthType shibboleth ShibRequireSession On Require valid-user </Location> ServerName 192.168.0.2 CAROUX Félicien NEMPONT Maxime Page 8

Observe, we use the SP s certificate and key. By default, the SP s installation doesn t provide a key and a certificate. So we must generate them as follow. #openssl genrsa -out SP.key 1024 #openssl req -new -key SP.key -out SP.csr #openssl x509 -req -days 365 -in SP.csr -signkey SP.key -out SP.crt #rm SP.csr To finish with Apache, enable the sites and mods that we are using and don t forget to restart Apache. #a2ensite default-ssl #a2enmod ssl #/etc/init.d/shibd restart Now, let s configure the shibboleth stack for the SP. In /etc/shibboleth/, there are a lot of XML files to configure shibboleth as we want. For example, we can quote the attributefilter.xml and attribute-resolver.xml, dedicated to the attributes management. In our primary configuration, the main file is etc/shibboleth/shibboleth2.xml. Edit this file and change the values of the host name, the entityid and the homeurl. #nano /etc/shibboleth/shibboleth2.xml <RequestMap applicationid= default > <Host name="192.168.0.2"> <ApplicationDefaults id="default" policyid="default" entityid="https://192.168.0.2/sp" homeurl="https://192.168.0.2/index.html" > Change the value of the entityid in the SessionInitiator tag. #nano /etc/shibboleth/shibboleth2.xml <SessionInitiator type="chaining" Location="/Login" isdefault="true" id="intranet" relaystate="cookie" entityid="https://192.168.0.1/idp/shibboleth"> CAROUX Félicien NEMPONT Maxime Page 9

Thanks to the following sentence that we add, shibboleth will able to load the IDP s metadata. #nano /etc/shibboleth/shibboleth2.xml <MetadataProvider type="xml" file="/home/user/desktop/idpmetadata"/> Don t forget too in this file, to change the values of key and certificate to allow shibboleth to load correct key and certificate. #nano /etc/shibboleth/shibboleth2.xml <CredentialResolver type="file" key="sp.key" certificate="sp.crt"/> Then, restart shibboleth with this command: #/etc/init.d/shibd restart Generate the SP s metadata thanks to the following link and save it for example in the Desktop: http://127.0.0.1/shibboleth.sso/metadata Then, use SSH on SP to transfer the metadata. #scp /home/user/desktop/metadata 192.168.0.1:/home/user/Desktop/SPMetadata To test the service provider, create finally a HTML file in /var/www/secure. #cd /var/www/ #mkdir /secure #nano /secure/index.html 5. Final tests Check if shibboleth works correctly thanks to this link : https://192.168.0.2/secure. In a correct run, the website asks you an authentication. Observe, no authentication is asked you when you access to the Apache s default page https://192.168.0.2/index.html. It s normal because only the /secure, it s secured by shibboleth. For more information about the shibboleth session, you can go with your browser to the following link: https://192.168.0.2/shibboleth.sso/session For more details on the shibboleth s exchange, you can check the logs. On the SP #tail f /var/log/shibboleth/shibd.log CAROUX Félicien NEMPONT Maxime Page 10

On the IDP #tail f /usr/local/idp/logs/idp-process.log Of course, we can configure the level of logs by editing the following files (change values on DEBUG ): On IDP, #nano /usr/local/idp/conf/logging.xml On SP, #nano /etc/shibboleth/shibd.logger CAROUX Félicien NEMPONT Maxime Page 11

6. Bibliography Virtual environment: http://www.linux-kvm.org http://www.lefinnois.net/wp/index.php/2007/10/13/debian-et-machine-virtuelle-kvm/ Shibboleth: Course book GAEL : Guide de l Authentification en Environnements Libres M. Jacques Landru TELECOM LILLE 1 push-method : https://federation.renater.fr/faq/shibboleth First How-to : https://testshib.org/testshib-two/install.jsp Second How-to : http://www-public.intevry.fr/~procacci/wiki/bin/view/documentations/shibspv2#2%20installation Third How-to : https://federation.cru.fr/doc/support-tp-idp.pdf Official shibboleth site : https://spaces.internet2.edu/display/shib2/home Help for the certificate : http://impetus.us/~rjmooney/projects/misc/clientcertauth.html

7. Apendix IDP: httpd.conf <Location /idp/authn/remoteuser> AuthType Basic AuthName "My Identity Provider" AuthUserFile /usr/local/idp/credentials/user.db require valid-user </Location> ProxyPass /idp/ ajp://127.0.0.1:8009/idp/ ProxyPass /jsp-examples/ ajp://127.0.0.1:8009/jsp-examples/ SSLCertificateFile /usr/local/idp/credentials/idp.crt SSLCertificateKeyFile /usr/local/idp/credentials/idp.key SSLVerifyClient optional_no_ca SSLVerifyDepth 10

IDP: logging.xml <?xml version="1.0" encoding="utf-8"?> <configuration> <!-- Loggers define indicate which packages/categories are logged, at which level, and to which appender. Levels: OFF, ERROR, WARN, INFO, DEBUG, TRACE, ALL <!-- Logs IdP, but not OpenSAML, messages <logger name="edu.internet2.middleware.shibboleth"> <level value="debug" /> </logger> <!-- Logs OpenSAML, but not IdP, messages <logger name="org.opensaml"> <level value="debug" /> </logger> <!-- Logs LDAP related messages <logger name="edu.vt.middleware.ldap"> <level value="warn"/> </logger> <!-- Logs inbound and outbound protocols messages at DEBUG level <logger name="protocol_message"> <level value="debug" /> </logger> <!-- Normally you should not edit below this point. These default configurations are sufficient for almost every system. <!-- Logging appenders define where and how logging messages are logged. <appender name="idp_access" class="ch.qos.logback.core.rolling.rollingfileappender"> <File>/usr/local/idp/logs/idp-access.log</File> <ImmediateFlush>true</ImmediateFlush> <rollingpolicy class="ch.qos.logback.core.rolling.timebasedrollingpolicy"> <FileNamePattern>/usr/local/idp/logs/idp-access-%d{yyyy-MMdd}.log</FileNamePattern>

</rollingpolicy> <layout class="ch.qos.logback.classic.patternlayout"> <Pattern>%msg%n</Pattern> </layout> </appender> <appender name="idp_audit" class="ch.qos.logback.core.rolling.rollingfileappender"> <File>/usr/local/idp/logs/idp-audit.log</File> <ImmediateFlush>true</ImmediateFlush> <rollingpolicy class="ch.qos.logback.core.rolling.timebasedrollingpolicy"> <FileNamePattern>/usr/local/idp/logs/idp-audit-%d{yyyy-MMdd}.log</FileNamePattern> </rollingpolicy> <layout class="ch.qos.logback.classic.patternlayout"> <Pattern>%msg%n</Pattern> </layout> </appender> <appender name="idp_process" class="ch.qos.logback.core.rolling.rollingfileappender"> <File>/usr/local/idp/logs/idp-process.log</File> <!-- Uncomment this if application is terminating in such as way that the last few log messages are not written to disk <!-- <ImmediateFlush>true</ImmediateFlush> <rollingpolicy class="ch.qos.logback.core.rolling.timebasedrollingpolicy"> <FileNamePattern>/usr/local/idp/logs/idp-process-%d{yyyy-MMdd}.log</FileNamePattern> </rollingpolicy> <layout class="ch.qos.logback.classic.patternlayout"> <!-- General logging pattern <Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - %msg%n</pattern> <!-- Two MDC variables are available for authenticated users: 'idpsessionid' and 'principalname'. You may include these the data in the logging pattern by means of %mdc{name} You may include the thread ID by means of %t <!-- Example logging pattern using thread ID and principal name <!-- <Pattern>%date{HH:mm:ss.SSS} - %level [%logger:%line] - [%t:%mdc{principalname}] - %msg%n</pattern>

</layout> </appender> <logger name="shibboleth-access"> <level value="all" /> <appender-ref ref="idp_access" /> </logger> <logger name="shibboleth-audit"> <level value="all" /> <appender-ref ref="idp_audit" /> </logger> <logger name="org.springframework"> <level value="off" /> </logger> <logger name="org.apache.catalina"> <level value="error" /> </logger> <root> <level value="error" /> <appender-ref ref="idp_process" /> </root> </configuration>

IDP: ports.conf # If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default # This is also true if you have upgraded from before 2.2.9-3 (i.e. from # Debian etch). See /usr/share/doc/apache2.2-common/news.debian.gz and # README.Debian.gz NameVirtualHost *:80 Listen 80 <IfModule mod_ssl.c> # SSL name based virtual hosts are not yet supported, therefore no # NameVirtualHost statement here Listen 8443 Listen 443 </IfModule>

IDP: relying-party.xml <?xml version="1.0" encoding="utf-8"?> <!-- This file is an EXAMPLE configuration file. This file specifies relying party dependent configurations for the IdP, for example, whether SAML assertions to a particular relying party should be signed. It also includes metadata provider and credential definitions used when answering requests to a relying party. <RelyingPartyGroup xmlns="urn:mace:shibboleth:2.0:relying-party" xmlns:saml="urn:mace:shibboleth:2.0:relying-party:saml" xmlns:metadata="urn:mace:shibboleth:2.0:metadata" xmlns:resource="urn:mace:shibboleth:2.0:resource" xmlns:security="urn:mace:shibboleth:2.0:security" xmlns:samlsec="urn:mace:shibboleth:2.0:security:saml" xmlns:samlmd="urn:oasis:names:tc:saml:2.0:metadata" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="urn:mace:shibboleth:2.0:relying-party classpath:/schema/shibboleth-2.0-relying-party.xsd urn:mace:shibboleth:2.0:relying-party:saml classpath:/schema/shibboleth-2.0-relying-party-saml.xsd urn:mace:shibboleth:2.0:metadata classpath:/schema/shibboleth-2.0- metadata.xsd urn:mace:shibboleth:2.0:resource classpath:/schema/shibboleth-2.0- resource.xsd urn:mace:shibboleth:2.0:security classpath:/schema/shibboleth-2.0- security.xsd urn:mace:shibboleth:2.0:security:saml classpath:/schema/shibboleth- 2.0-security-policy-saml.xsd urn:oasis:names:tc:saml:2.0:metadata classpath:/schema/samlschema-metadata-2.0.xsd"> <!-- ========================================== <!-- Relying Party Configurations <!-- ========================================== <AnonymousRelyingParty provider="https://192.168.0.1/idp/shibboleth" defaultsigningcredentialref="idpcredential" /> <DefaultRelyingParty provider="https://192.168.0.1/idp/shibboleth" defaultsigningcredentialref="idpcredential"> <!-- Each attribute in these profiles configuration is set to its default value, that is, the values that would be in effect if those attributes were not present. We list them here so that people are aware of them (since they seem reluctant to read the documentation).

<ProfileConfiguration xsi:type="saml:shibbolethssoprofile" includeattributestatement="false" assertionlifetime="300000" signresponses="always" signassertions="always" /> <ProfileConfiguration xsi:type="saml:saml1attributequeryprofile" assertionlifetime="300000" signresponses="conditional" signassertions="never" /> <ProfileConfiguration xsi:type="saml:saml1artifactresolutionprofile" signresponses="conditional" signassertions="never" /> <ProfileConfiguration xsi:type="saml:saml2ssoprofile" includeattributestatement="true" assertionlifetime="300000" assertionproxycount="0" signresponses="conditional" signassertions="never" encryptassertions="conditional" encryptnameids="never" /> <ProfileConfiguration xsi:type="saml:saml2attributequeryprofile" assertionlifetime="300000" assertionproxycount="0" signresponses="conditional" signassertions="never" encryptassertions="conditional" encryptnameids="never" /> <ProfileConfiguration xsi:type="saml:saml2artifactresolutionprofile" signresponses="conditional" signassertions="never" encryptassertions="conditional" encryptnameids="never"/> </DefaultRelyingParty> <!-- ========================================== <!-- Metadata Configuration <!-- ========================================== <!-- MetadataProvider the combining other MetadataProviders <MetadataProvider id="shibbolethmetadata" xsi:type="chainingmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata"> <!-- Load the IdP's own metadata. This is necessary for artifact support.

<MetadataProvider id="idpmd" xsi:type="resourcebackedmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata" > <MetadataResource xsi:type="resource:filesystemresource" file="/usr/local/idp/metadata/idp-metadata.xml" /> </MetadataProvider> <MetadataProvider xsi:type="filesystemmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata" id="mymetadata" metadatafile="/home/binome/desktop/spmetadata"> </MetadataProvider> <!-- Example metadata provider. <!-- Reads metadata from a URL and store a backup copy on the file system. <!-- Validates the signature of the metadata and filters out all by SP entities in order to save memory <!-- To use: fill in 'metadataurl' and 'backingfile' properties on MetadataResource element <!-- <MetadataProvider id="urlmd" xsi:type="filebackedhttpmetadataprovider" xmlns="urn:mace:shibboleth:2.0:metadata" metadataurl="http://example.org/metadata.xml" backingfile="/usr/local/idp/metadata/some-metadata.xml"> <MetadataFilter xsi:type="chainingfilter" xmlns="urn:mace:shibboleth:2.0:metadata"> <MetadataFilter xsi:type="requiredvaliduntil" xmlns="urn:mace:shibboleth:2.0:metadata" maxvalidityinterval="604800" /> <MetadataFilter xsi:type="signaturevalidation" xmlns="urn:mace:shibboleth:2.0:metadata" trustengineref="shibboleth.metadatatrustengine" requiresignedmetadata="true" /> <MetadataFilter xsi:type="entityrolewhitelist" xmlns="urn:mace:shibboleth:2.0:metadata"> <RetainedRole>samlmd:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataFilter> </MetadataProvider> </MetadataProvider> <!-- ========================================== <!-- Security Configurations <!-- ========================================== <security:credential id="idpcredential" xsi:type="security:x509filesystem"> <security:privatekey>/usr/local/idp/credentials/idp.key</security:privatekey> <security:certificate>/usr/local/idp/credentials/idp.crt</security:certificate> </security:credential>

<!-- Trust engine used to evaluate the signature on loaded metadata. <!-- <security:trustengine id="shibboleth.metadatatrustengine" xsi:type="security:staticexplicitkeysignature"> <security:credential id="myfederation1credentials" xsi:type="security:x509filesystem"> <security:certificate>/usr/local/idp/credentials/federation1.crt</security:certificate> </security:credential> </security:trustengine> <!-- DO NOT EDIT BELOW THIS POINT <!-- The following trust engines and rules control every aspect of security related to incoming messages. Trust engines evaluate various tokens (like digital signatures) for trust worthiness while the security policies establish a set of checks that an incoming message must pass in order to be considered secure. Naturally some of these checks require the validation of the tokens evaluated by the trust engines and so you'll see some rules that reference the declared trust engines. <security:trustengine id="shibboleth.signaturetrustengine" xsi:type="security:signaturechaining"> <security:trustengine id="shibboleth.signaturemetadataexplicitkeytrustengine" xsi:type="security:metadataexplicitkeysignature" metadataproviderref="shibbolethmetadata" /> <security:trustengine id="shibboleth.signaturemetadatapkixtrustengine" xsi:type="security:metadatapkixsignature" metadataproviderref="shibbolethmetadata" /> </security:trustengine> <security:trustengine id="shibboleth.credentialtrustengine" xsi:type="security:chaining"> <security:trustengine id="shibboleth.credentialmetadataexplictkeytrustengine" xsi:type="security:metadataexplicitkey" metadataproviderref="shibbolethmetadata" /> <security:trustengine id="shibboleth.credentialmetadatapkixtrustengine" xsi:type="security:metadatapkixx509credential" metadataproviderref="shibbolethmetadata" /> </security:trustengine> <security:securitypolicy id="shibboleth.shibbolethssosecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:issueinstant" required="false"/> <security:rule xsi:type="samlsec:mandatoryissuer"/> </security:securitypolicy>

<security:securitypolicy id="shibboleth.saml1attributequerysecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="security:clientcertauth" trustengineref="shibboleth.credentialtrustengine" /> <security:rule xsi:type="samlsec:mandatoryissuer"/> <security:rule xsi:type="security:mandatorymessageauthentication" /> </security:securitypolicy> <security:securitypolicy id="shibboleth.saml1artifactresolutionsecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="security:clientcertauth" trustengineref="shibboleth.credentialtrustengine" /> <security:rule xsi:type="samlsec:mandatoryissuer"/> <security:rule xsi:type="security:mandatorymessageauthentication" /> </security:securitypolicy> <security:securitypolicy id="shibboleth.saml2ssosecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:saml2authnrequestssigned"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httpredirectsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httppostsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:mandatoryissuer"/> </security:securitypolicy> <security:securitypolicy id="shibboleth.saml2attributequerysecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httpredirectsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httppostsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="security:clientcertauth" trustengineref="shibboleth.credentialtrustengine" />

<security:rule xsi:type="samlsec:mandatoryissuer"/> <security:rule xsi:type="security:mandatorymessageauthentication" /> </security:securitypolicy> <security:securitypolicy id="shibboleth.saml2artifactresolutionsecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httpredirectsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httppostsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="security:clientcertauth" trustengineref="shibboleth.credentialtrustengine" /> <security:rule xsi:type="samlsec:mandatoryissuer"/> <security:rule xsi:type="security:mandatorymessageauthentication" /> </security:securitypolicy> <security:securitypolicy id="shibboleth.saml2slosecuritypolicy" xsi:type="security:securitypolicytype"> <security:rule xsi:type="samlsec:replay"/> <security:rule xsi:type="samlsec:issueinstant"/> <security:rule xsi:type="samlsec:protocolwithxmlsignature" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httpredirectsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="samlsec:saml2httppostsimplesign" trustengineref="shibboleth.signaturetrustengine" /> <security:rule xsi:type="security:clientcertauth" trustengineref="shibboleth.credentialtrustengine" /> <security:rule xsi:type="samlsec:mandatoryissuer"/> <security:rule xsi:type="security:mandatorymessageauthentication" /> </security:securitypolicy> </RelyingPartyGroup>

IDP: ssl8443 <IfModule mod_ssl.c> <VirtualHost _default_:8443> ServerAdmin webmaster@localhost DocumentRoot /var/www/ <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/ssl_access.log combined Alias /doc/ "/usr/share/doc/" <Directory "/usr/share/doc/"> Options Indexes MultiViews FollowSymLinks AllowOverride None Order deny,allow Deny from all Allow from 127.0.0.0/255.0.0.0 ::1/128 </Directory> # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # A self-signed (snakeoil) certificate can be created by installing # the ssl-cert package. See # /usr/share/doc/apache2.2-common/readme.debian.gz for more info.

# If both key and certificate are stored in the same file, only the # SSLCertificateFile directive is needed. #SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem #SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER}!~ m/^(exp NULL)/ \

# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31zmtzzkva'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi shtml phtml php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates

# the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. BrowserMatch ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule>

IDP s metadata <?xml version="1.0" encoding="utf-8"?><entitydescriptor xmlns="urn:oasis:names:tc:saml:2.0:metadata" entityid="https://192.168.0.1/idp/shibboleth" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"><idpssodescriptor protocolsupportenumeration="urn:mace:shibboleth:1.0 urn:oasis:names:tc:saml:1.1:protocol urn:oasis:names:tc:saml:2.0:protocol"><extensions><shibmd:scope regexp="false">0.1</shibmd:scope></extensions><keydescriptor><ds:keyinfo><ds:x509 Data><ds:X509Certificate>MIIDFzCCAf+gAwIBAgIUJFoRhZM+TMUKaqRoRJ4vUHRyV gowdqyjkozihvcnaqef BQAwFjEUMBIGA1UEAxMLMTkyLjE2OC4wLjEwHhcNMDkxMTIzMTU0NTE1WhcN Mjkx MTIzMTU0NTE1WjAWMRQwEgYDVQQDEwsxOTIuMTY4LjAuMTCCASIwDQYJKoZ IhvcN AQEBBQADggEPADCCAQoCggEBALZhnktNTzAk3Ax5hw0bjZwntnZkD/bUWGQZ691r Cuh6MKnamkmDt1mYN47LET4iZD/EkSwNI6G6ZeoboRAAA2J1vutyYmJasyWK1eyH pd8wjfbwuqwwk3bpnjqc6doa6mami/bdivkq1ckhc6pyipylhi110kyc9yrmtog0 msuhue5l7msdwdww3jgjujgmyslup1te0n4wxnemf+z9gxgvnfegxu4ksh/kbeum xc9w6prsw9tkopuiv2qvnhch0leb7fmdpf73tsyzd4gsezdzpamw8zpn5nmk1gej lhyfhahwisak7ffaeu+75qkjttesu7sh2dkwqqabgtd7bdecaweaaandmfswogyd VR0RBDMwMYILMTkyLjE2OC4wLjGGImh0dHBzOi8vMTkyLjE2OC4wLjEvaWRwL3N o awjib2xldggwhqydvr0obbyefl0mwrs/k409itliqpjr+ndaa45lma0gcsqgsib3 DQEBBQUAA4IBAQCeyDO6S+sHEt7iXuAnmndIKa4BgKHePl01ePdE4PyNx0qqH/E0 fwnhto1m/itlrn5m9hefuwfnximyexjgg6ebx7+aunfp4/b+/vbuuwola/y4nhvf 6tBwLKpQZIkupfqfBdx7d9MbWVQ9oxleScWzZyVc3j/rriqqTKi8BHoUrm2bd+gj /IgYFZSi0ESbPkf5pLhAxFeZQpWxwZ6QqdnJsiVaaHvSh6Bha6etxTjbN5NOpQFh RxlXrOxY2/6U0fyNPsAXr65RYS2Mt8uH618tm3hqjUnpSvfxp0O8fsnQZGAvsWmd XUrfThTGvZjng82kzzCGYXQguy/t7Pa3rsRl</ds:X509Certificate></ds:X509Data></ds:Ke yinfo></keydescriptor><artifactresolutionservice Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://192.168.0.1:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/><artifactresolutionservice Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://192.168.0.1:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/><nameidformat>urn:mace:shibboleth:1.0:nameidentifier</nameidformat><na meidformat>urn:oasis:names:tc:saml:2.0:nameidformat:transient</nameidformat><singlesignonservice Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://192.168.0.1/idp/profile/Shibboleth/SSO"/><SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://192.168.0.1/idp/profile/SAML2/POST/SSO"/><SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://192.168.0.1/idp/profile/SAML2/POST- SimpleSign/SSO"/><SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"

Location="https://192.168.0.1/idp/profile/SAML2/Redirect/SSO"/></IDPSSODescriptor><At tributeauthoritydescriptor protocolsupportenumeration="urn:oasis:names:tc:saml:1.1:protocol urn:oasis:names:tc:saml:2.0:protocol"><extensions><shibmd:scope regexp="false">0.1</shibmd:scope></extensions><keydescriptor><ds:keyinfo><ds:x509 Data><ds:X509Certificate>MIIDFzCCAf+gAwIBAgIUJFoRhZM+TMUKaqRoRJ4vUHRyV gowdqyjkozihvcnaqef BQAwFjEUMBIGA1UEAxMLMTkyLjE2OC4wLjEwHhcNMDkxMTIzMTU0NTE1WhcN Mjkx MTIzMTU0NTE1WjAWMRQwEgYDVQQDEwsxOTIuMTY4LjAuMTCCASIwDQYJKoZ IhvcN AQEBBQADggEPADCCAQoCggEBALZhnktNTzAk3Ax5hw0bjZwntnZkD/bUWGQZ691r Cuh6MKnamkmDt1mYN47LET4iZD/EkSwNI6G6ZeoboRAAA2J1vutyYmJasyWK1eyH pd8wjfbwuqwwk3bpnjqc6doa6mami/bdivkq1ckhc6pyipylhi110kyc9yrmtog0 msuhue5l7msdwdww3jgjujgmyslup1te0n4wxnemf+z9gxgvnfegxu4ksh/kbeum xc9w6prsw9tkopuiv2qvnhch0leb7fmdpf73tsyzd4gsezdzpamw8zpn5nmk1gej lhyfhahwisak7ffaeu+75qkjttesu7sh2dkwqqabgtd7bdecaweaaandmfswogyd VR0RBDMwMYILMTkyLjE2OC4wLjGGImh0dHBzOi8vMTkyLjE2OC4wLjEvaWRwL3N o awjib2xldggwhqydvr0obbyefl0mwrs/k409itliqpjr+ndaa45lma0gcsqgsib3 DQEBBQUAA4IBAQCeyDO6S+sHEt7iXuAnmndIKa4BgKHePl01ePdE4PyNx0qqH/E0 fwnhto1m/itlrn5m9hefuwfnximyexjgg6ebx7+aunfp4/b+/vbuuwola/y4nhvf 6tBwLKpQZIkupfqfBdx7d9MbWVQ9oxleScWzZyVc3j/rriqqTKi8BHoUrm2bd+gj /IgYFZSi0ESbPkf5pLhAxFeZQpWxwZ6QqdnJsiVaaHvSh6Bha6etxTjbN5NOpQFh RxlXrOxY2/6U0fyNPsAXr65RYS2Mt8uH618tm3hqjUnpSvfxp0O8fsnQZGAvsWmd XUrfThTGvZjng82kzzCGYXQguy/t7Pa3rsRl</ds:X509Certificate></ds:X509Data></ds:Ke yinfo></keydescriptor><attributeservice Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://192.168.0.1:8443/idp/profile/SAML1/SOAP/AttributeQuery"/><AttributeS ervice Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://192.168.0.1:8443/idp/profile/SAML2/SOAP/AttributeQuery"/><NameIDF ormat>urn:mace:shibboleth:1.0:nameidentifier</nameidformat><nameidformat>urn:oasis :names:tc:saml:2.0:nameidformat:transient</nameidformat></attributeauthoritydescriptor></entitydescriptor>

SP: httpd.conf UseCanonicalName On # RPM installations on platforms with a conf.d directory will # result in this file being copied into that directory for you. # For non-rpm installs, you can add this file to your # configuration using an Include command in httpd.conf ###### ## SHIB Config ###### # # Load the SHIBBOLETH module # LoadModule mod_shib /usr/lib/apache2/modules/mod_shib_22.so # # Used for example logo and style sheet in error templates. # <IfModule mod_alias.c> <Location /shibboleth-sp> Allow from all </Location> Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css Alias /shibboleth-sp/logo.jpg /usr/share/shibboleth/logo.jpg </IfModule> # # Configure the module for content # # You can now do most of this in shibboleth.xml using the RequestMap # but you MUST enable AuthType shibboleth for the module to process # any requests, and there MUST be a require command as well. To # enable Shibboleth but not specify any session/access requirements # use "require shibboleth". #SSLCertificateFile /etc/pki/tls/certs/server.crt #SSLCertificateKeyFile /etc/pki/tls/private/server.key #SSLCACertificateFile /etc/pki/tls/certs/ca.crt SSLCertificateFile /etc/shibboleth/sp.crt SSLCertificateKeyFile /etc/shibboleth/sp.key SSLVerifyClient optional_no_ca SSLverifyDepth 10 <Location /secure> AuthType shibboleth ShibRequireSession On

#ShibRequestSetting requiresession 1 Require valid-user </Location> ServerName 192.168.0.2

SP: ports.conf # If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default # This is also true if you have upgraded from before 2.2.9-3 (i.e. from # Debian etch). See /usr/share/doc/apache2.2-common/news.debian.gz and # README.Debian.gz NameVirtualHost *:80 Listen 80 <IfModule mod_ssl.c> # SSL name based virtual hosts are not yet supported, therefore no # NameVirtualHost statement here Listen 443 </IfModule>

SP: shibboleth2.xml <SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config" xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:md="urn:oasis:names:tc:saml:2.0:metadata" logger="syslog.logger" clockskew="180"> <!-- The OutOfProcess section contains properties affecting the shibd daemon. <OutOfProcess logger="shibd.logger"> <!-- <Extensions> <Library path="odbc-store.so" fatal="true"/> </Extensions> </OutOfProcess> <!-- The InProcess section conrains settings affecting web server modules/filters. <InProcess logger="native.logger"> <ISAPI normalizerequest="true"> <!-- Maps IIS Instance ID values to the host scheme/name/port/sslport. The name is required so that the proper <Host> in the request map above is found without having to cover every possible DNS/IP combination the user might enter. The port and scheme can usually be omitted, so the HTTP request's port and scheme will be used. <Site id="1" name="sp.example.org"/> </ISAPI> </InProcess> <!-- Only one listener can be defined, to connect in process modules to shibd. <UnixListener address="shibd.sock"/> <!-- <TCPListener address="127.0.0.1" port="12345" acl="127.0.0.1"/> <!-- This set of components stores sessions and other persistent data in daemon memory. -- > <StorageService type="memory" id="mem" cleanupinterval="900"/> <SessionCache type="storageservice" StorageService="mem" cachetimeout="3600" inproctimeout="900" cleanupinterval="900"/> <ReplayCache StorageService="mem"/> <ArtifactMap artifactttl="180"/> <!-- This set of components stores sessions and other persistent data in an ODBC database. <!-- <StorageService type="odbc" id="db" cleanupinterval="900"> <ConnectionString>

DRIVER=drivername;SERVER=dbserver;UID=shibboleth;PWD=password;DATABASE=sh ibboleth;app=shibboleth </ConnectionString> </StorageService> <SessionCache type="storageservice" StorageService="db" cachetimeout="3600" inproctimeout="900" cleanupinterval="900"/> <ReplayCache StorageService="db"/> <ArtifactMap StorageService="db" artifactttl="180"/> <!-- To customize behavior, map hostnames and path components to applicationid and other settings. <RequestMapper type="native"> <RequestMap applicationid="default"> <!-- The example requires a session for documents in /secure on the containing host with http and https on the default ports. Note that the name and port in the <Host> elements MUST match Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element below. <Host name="192.168.0.2"> <Path name="secure" authtype="shibboleth" requiresession="true"/> </Host> <!-- Example of a second vhost mapped to a different applicationid. <!-- <Host name="admin.example.org" applicationid="admin" authtype="shibboleth" requiresession="true"/> </RequestMap> </RequestMapper> <!-- The ApplicationDefaults element is where most of Shibboleth's SAML bits are defined. Resource requests are mapped by the RequestMapper to an applicationid that points into to this section. <ApplicationDefaults id="default" policyid="default" entityid="https://192.168.0.2/sp" homeurl="https://192.168.0.2/index.html" REMOTE_USER="eppn persistent-id targeted-id" signing="false" encryption="false" > <!-- Controls session lifetimes, address checks, cookie handling, and the protocol handlers. You MUST supply an effectively unique handlerurl value for each of your applications.

The value can be a relative path, a URL with no hostname (https:///path) or a full URL. The system can compute a relative value based on the virtual host. Using handlerssl="true" will force the protocol to be https. You should also add a cookieprops setting of "; path=/; secure" in that case. Note that while we default checkaddress to "false", this has a negative impact on the security of the SP. Stealing cookies/sessions is much easier with this disabled. <Sessions lifetime="28800" timeout="3600" checkaddress="false" handlerurl="/shibboleth.sso" handlerssl="false" exportlocation="http://localhost/shibboleth.sso/getassertion" idphistory="false" idphistorydays="7"> <!-- SessionInitiators handle session requests and relay them to a Discovery page, or to an IdP if possible. Automatic session setup will use the default or first element (or requiresessionwith can specify a specific id to use). <!-- Default example directs to a specific IdP's SSO service (favoring SAML 2 over Shib 1). <SessionInitiator type="chaining" Location="/Login" isdefault="true" id="intranet" relaystate="cookie" entityid="https://192.168.0.1/idp/shibboleth"> <SessionInitiator type="saml2" defaultacsindex="1" template="bindingtemplate.html"/> <SessionInitiator type="shib1" defaultacsindex="5"/> </SessionInitiator> <!-- An example using an old-style WAYF, which means Shib 1 only unless an entityid is provided. <SessionInitiator type="chaining" Location="/WAYF" id="wayf" relaystate="cookie"> <SessionInitiator type="saml2" defaultacsindex="1" template="bindingtemplate.html"/> <SessionInitiator type="shib1" defaultacsindex="5"/> <SessionInitiator type="wayf" defaultacsindex="5" URL="https://wayf.example.org/WAYF"/> </SessionInitiator> <!-- An example supporting the new-style of discovery service. <SessionInitiator type="chaining" Location="/DS" id="ds" relaystate="cookie"> <SessionInitiator type="saml2" defaultacsindex="1" template="bindingtemplate.html"/> <SessionInitiator type="shib1" defaultacsindex="5"/> <SessionInitiator type="samlds" URL="https://ds.example.org/DS"/> </SessionInitiator> <!-- md:assertionconsumerservice locations handle specific SSO protocol bindings,