This is an old revision of the document!
[root@idp5 ~]# dnf install java-17-openjdk java-17-openjdk-devel^C [root@idp5 ~]# java --version openjdk 17.0.11 2024-04-16 LTS OpenJDK Runtime Environment (Red_Hat-17.0.11.0.9-3) (build 17.0.11+9-LTS) OpenJDK 64-Bit Server VM (Red_Hat-17.0.11.0.9-3) (build 17.0.11+9-LTS, mixed mode, sharing)
[root@idp5 ~]# dnf install httpd [root@idp5 ~]# systemctl start httpd [root@idp5 ~]# systemctl enable httpd Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[root@idp5 ~]# mkdir /opt/tomcat [root@idp5 ~]# cd /opt [root@idp5 opt]# wget https://downloads.apache.org/tomcat/tomcat-10/v10.1.20/bin/apache-tomcat-10.1.20.tar.gz -O tomcat-10.1.20.tar.gz [root@idp5 opt]# tar xzvf tomcat-10.1.20.tar.gz -C /opt/tomcat --strip-components=1 [root@idp5 opt]# useradd -m -U -d /opt/tomcat -s /bin/false tomcat [root@idp5 opt]# chown tomcat:tomcat -R /opt/tomcat/
gestion du service par systemd
[root@idp5 opt]# touch /etc/systemd/system/tomcat.service [root@idp5 opt]# vim /etc/systemd/system/tomcat.service [root@idp5 opt]# systemctl daemon-reload [root@idp5 opt]# systemctl start tomcat && systemctl enable tomcat Created symlink /etc/systemd/system/multi-user.target.wants/tomcat.service → /etc/systemd/system/tomcat.service.
avec system/tomcat.service
[root@idp5 opt]# cat /etc/systemd/system/tomcat.service [Unit] Description=Apache Tomcat After=network.target [Service] Type=forking User=tomcat Group=tomcat Environment="JAVA_HOME=/usr/lib/jvm/jre" Environment="JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom" Environment="CATALINA_BASE=/opt/tomcat" Environment="CATALINA_HOME=/opt/tomcat" Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid" Environment="CATALINA_OPTS=-Xms512M -Xmx1536M -server -XX:+UseParallelGC" ExecStart=/opt/tomcat/bin/startup.sh ExecStop=/opt/tomcat/bin/shutdown.sh ExecReload=/bin/kill $MAINPID RemainAfterExit=yes [Install] WantedBy=multi-user.target
tomcat listen on port 8080 , on ouvre ce port pour test inital avant reverse proxy-apache a notre station d'admin et localhost
[root@idp5]# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.0.11/32" port port=8080 protocol=tcp log prefix="tomcat8080" accept' [root@idp5 ~]# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="127.0.0.1" port port=8080 protocol=tcp log prefix="tomcat8080" accept' [root@idp5]# firewall-cmd --reload
on peux alors tester un acces direct a notre serveur tomcat sur le port 8080
si on souhaite autoriser l'acce à l'application manager il faut ajouter des roles et usernames dans tomcat-users.xml
<role rolename="manager-gui"/> <role rolename="manager-status"/> <!-- jehan usernames --> <user username="admin" password="secret1" roles="manager-gui"/> <user username="admstat" password="secret2" roles="manager-status"/>
on se sert d'apache en reverse-proxy (frontal) pour tomcat, il gerera notament le service TLS car c'est le mod_ssl apache qui est en frontal
[root@idp5 ~]# touch /etc/httpd/conf.d/tomcat.conf [root@idp5 ~]# vim /etc/httpd/conf.d/tomcat.conf
avec ce fichier de conf apache reverse-proxy-tomcat on gere les acces http , ici exemple en AJP
<VirtualHost *:80> ServerName idp5mt.imtbs-tsp.eu ProxyRequests off ProxyPass /idp ajp://127.0.0.1:8009/idp retry=0 ProxyPassReverse /idp ajp://127.0.0.1:8009/idp ProxyPass /manager ajp://127.0.0.1:8009/manager ProxyPassReverse /manager ajp://127.0.0.1:8009/manager </VirtualHost>
Exemple en http pour le httpS ⇒ utilisé en production
#httpS <VirtualHost *:443> ServerName idp5mt.imtbs-tsp.eu ProxyRequests off ProxyPass /idp http://127.0.0.1:8080/idp retry=0 ProxyPassReverse /idp http://127.0.0.1:8080/idp ProxyPass /manager http://127.0.0.1:8080/manager ProxyPassReverse /manager http://127.0.0.1:8080/manager </VirtualHost>
Pour nginx : https://computingforgeeks.com/install-apache-tomcat-on-centos-rocky-linux/
Si on utilise AJP comme protocol intermedaire entre apache-httpd et apchache-tomcat il faut configurer le proxy-ajp pour rediriger les requetes https d'apache vers tomcat , ici avec 2 application redirigé, notre futir /idp et le /manager de tomcat
[root@idpx ~]# cat /etc/httpd/conf.d/tomcat.conf ProxyPass /idp ajp://127.0.0.1:8009/idp retry=0 ProxyPassReverse /idp ajp://127.0.0.1:8009/idp ProxyPass /manager ajp://127.0.0.1:8009/manager ProxyPassReverse /manager ajp://127.0.0.1:8009/manager
activer le connecteur AJP coté tomcat
[root@idp5 opt]# vim /opt/tomcat/conf/server.xml
<!-- Define an AJP 1.3 Connector on port 8009 -->
<!-- uncomment AJP -->
<Connector protocol="AJP/1.3"
address="::1"
port="8009"
redirectPort="8443"
maxParameterCount="1000"
secretRequired="false"
sans l'option secretRequired=“false” (cf https://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp ) , impossible d'acceder au manager via proxy_ajp, il faudrai mieux controler cet acces en limitant les acces proxy uniquement a 127.0.0.1 entre httpd et tomcat , sinon positioner un secret .
lancement httpd et verification de la presence du module AJP
[root@idpx opt]# systemctl start httpd.service [root@idpx opt]# httpd -M | grep ajp proxy_ajp_module (shared)
acces sans le port 8080 :
http://idpx.mondomain.fr/manager/html
puis en https via le proxy-ajp sans preciser du port 443 dans l'url
installer le module si pas deja present
[root@idp5 ~]# dnf install mod_ssl
penser a ouvrir le firewall sur le port 443 service httpS
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.0.0/16" service name="https" log prefix="https_myNet" accept' success
configurer le module SSL/TLS avec nos certificats
# grep "^[^#;]" /etc/httpd/conf.d/ssl.conf | grep SSL SSLEngine on SSLHonorCipherOrder on SSLCipherSuite PROFILE=SYSTEM SSLProxyCipherSuite PROFILE=SYSTEM SSLCertificateFile /etc/letsencrypt/live/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/chain.pem
[root@idp5 opt]# mkdir -p shibboleth/src [root@idp5 opt]# cd shibboleth/src/ [root@idp5 src]# wget https://shibboleth.net/downloads/identity-provider/latest5/shibboleth-identity-provider-5.1.2.tar.gz [root@idp5 src]# tar xvfz shibboleth-identity-provider-5.1.2.tar.gz
fresh install ici, attention en cas d'update ne pas tout ecraser les config !
[root@idp5 shibboleth-identity-provider-5.1.2]# ./bin/install.sh Installation Directory: [/opt/shibboleth-idp] ? INFO - New Install. Version: 5.1.2 Host Name: [102.168.1.5] ? idp5.mondomain.fr INFO - Creating idp-signing, CN = idp5.mondomain.fr URI = https://idp5.mondomain.fr/idp/shibboleth, keySize=3072 INFO - Creating idp-encryption, CN = idp5.mondomain.fr URI = https://idp5.mondomain.fr/idp/shibboleth, keySize=3072 INFO - Creating backchannel keystore, CN = idp5.mondomain.fr URI = https://idp5.mondomain.fr/idp/shibboleth, keySize=3072 INFO - Creating Sealer KeyStore INFO - No existing versioning property, initializing... SAML EntityID: [https://idp5.mondomain.fr/idp/shibboleth] ? Attribute Scope: [mondomain.fr] ? INFO - Initializing OpenSAML using the Java Services API INFO - Algorithm failed runtime support check, will not be usable: http://www.w3.org/2001/04/xmlenc#ripemd160 INFO - Algorithm failed runtime support check, will not be usable: http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160 INFO - Algorithm failed runtime support check, will not be usable: http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160 INFO - Including auto-located properties in /opt/shibboleth-idp/conf/services.properties INFO - Including auto-located properties in /opt/shibboleth-idp/conf/authn/authn.properties INFO - Including auto-located properties in /opt/shibboleth-idp/conf/admin/admin.properties INFO - Including auto-located properties in /opt/shibboleth-idp/conf/c14n/subject-c14n.properties INFO - Including auto-located properties in /opt/shibboleth-idp/conf/ldap.properties INFO - Including auto-located properties in /opt/shibboleth-idp/conf/saml-nameid.properties INFO - Creating Metadata to /opt/shibboleth-idp/metadata/idp-metadata.xml INFO - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 5.1.2 INFO - Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp INFO - Overlay from /opt/shibboleth-idp/edit-webapp to /opt/shibboleth-idp/webpapp.tmp INFO - Creating war file /opt/shibboleth-idp/war/idp.war
fichiers de credentials créés
[root@idp5 shibboleth-identity-provider-5.1.2]# ls -l /opt/shibboleth-idp/credentials/ total 36 -rw------- 1 root root 1525 May 4 20:46 idp-backchannel.crt -rw------- 1 root root 3554 May 4 20:46 idp-backchannel.p12 -rw------- 1 root root 1525 May 4 20:46 idp-encryption.crt -rw------- 1 root root 2455 May 4 20:46 idp-encryption.key -rw------- 1 root root 1525 May 4 20:46 idp-signing.crt -rw------- 1 root root 2459 May 4 20:46 idp-signing.key -rw------- 1 root root 502 May 4 20:46 sealer.jks -rw------- 1 root root 53 May 4 20:46 sealer.kver -rw------- 1 root root 733 May 4 20:46 secrets.properties
see Configure IdP Context Container
creation du fichier de context pour l'IDP
[root@idp5 tomcat]# vim conf/Catalina/localhost/idp.xml
[root@idp5 tomcat]# cat conf/Catalina/localhost/idp.xml
<Context docBase="${idp.home}/war/idp.war"
privileged="true"
swallowOutput="true"/>
définition de la variable d'environement *idp.home* au demarrage de tomcat
[root@idp5 tomcat]# vim /etc/systemd/system/tomcat.service [root@idp5 tomcat]# grep idp /etc/systemd/system/tomcat.service Environment="CATALINA_OPTS=-Xms512M -Xmx1536M -server -XX:+UseParallelGC -Didp.home=/opt/shibboleth-idp" [root@idp5 tomcat]# systemctl daemon-reload [root@idp5 tomcat]# systemctl restart tomcat.service
apres restart de tomcat , l'IDP (.war) est deployé
[root@idp5 tomcat]# ls /opt/tomcat/webapps/idp/ css images index.jsp js META-INF WEB-INF
donner la proprieté au user tomcat sur toute l'arborescence de l'IDP
[root@idp5 tomcat]# chown -R tomcat /opt/shibboleth-idp/
test d'acces primaire sur http://idp5.mondomain.fr/idp/status
au premier abord, cette page ne s'est pas affichée
logs/idp-process.log 2024-05-04 21:18:26,206 - 127.0.0.1 - ERROR [jakarta.servlet.ServletException:144] - jakarta.servlet.ServletException: Handler dispatch failed: java.lang.NoClassDefFoundError: jakarta/servlet/jsp/jstl/core/Config at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1104) Caused by: java.lang.NoClassDefFoundError: jakarta/servlet/jsp/jstl/core/Config
il faut installer le jar JSTL
cf
[root@idp5 tomcat]# cd /opt/shibboleth-idp/edit-webapp/ [root@idp5 edit-webapp]# mkdir -p WEB-INF/lib [root@idp5 edit-webapp]# cd WEB-INF/lib/ [root@idp5 lib]# wget https://repo.maven.apache.org/maven2/org/glassfish/web/jakarta.servlet.jsp.jstl/3.0.1/jakarta.servlet.jsp.jstl-3.0.1.jar [root@idp5 lib]# wget https://repo.maven.apache.org/maven2/jakarta/servlet/jsp/jstl/jakarta.servlet.jsp.jstl-api/3.0.0/jakarta.servlet.jsp.jstl-api-3.0.0.jar [root@idp5 lib]# ls -l total 3676 -rw-r--r-- 1 tomcat root 3711043 Sep 29 2022 jakarta.servlet.jsp.jstl-3.0.1.jar -rw-r--r-- 1 root root 46041 Mar 4 2022 jakarta.servlet.jsp.jstl-api-3.0.0.jar
puis rebuild de idp.war pour contenir cette librarie/jar
[root@idp5 lib]# cd /opt/shibboleth-idp/ [root@idp5 shibboleth-idp]# ./bin/build.sh INFO - net.shibboleth.idp.installer.impl.IdPBuildArguments@14899482 INFO - Rebuilding /opt/shibboleth-idp/./bin/../war/idp.war, Version 5.1.2 INFO - Initial populate from ./bin/../dist/webapp to ./bin/../webpapp.tmp INFO - Overlay from ./bin/../edit-webapp to ./bin/../webpapp.tmp INFO - Creating war file ./bin/../war/idp.war
l'auto-deploy de tomcat assure la diffusion de cette librairie dans l'arborescence webapps
[root@idp5 shibboleth-idp]# locate jakarta.servlet.jsp.jstl-3.0.1.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/jakarta.servlet.jsp.jstl-3.0.1.jar /opt/tomcat/webapps/idp/WEB-INF/lib/jakarta.servlet.jsp.jstl-3.0.1.jar [root@idp5 shibboleth-idp]# locate jakarta.servlet.jsp.jstl-api-3.0.0.jar /opt/shibboleth-idp/edit-webapp/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar /opt/tomcat/webapps/idp/WEB-INF/lib/jakarta.servlet.jsp.jstl-api-3.0.0.jar
le status fonctionne enfin : https://idp5.mondomain.fr/idp/status
### Operating Environment Information operating_system: Linux operating_system_version: 5.14.0 operating_system_architecture: amd64 jdk_version: 17.0.11 available_cores: 48 used_memory: 94 MB maximum_memory: 1365 MB ### Identity Provider Information idp_version: 5.1.2 start_time: 2024-05-04T19:59:57.926Z current_time: 2024-05-04T19:59:59.337061202Z uptime: PT1.411S enabled modules: idp.Core (Core IdP Functions (Required)) idp.CommandLine (Command Line Scripts) idp.EditWebApp (Overlay Tree for WAR Build) idp.authn.Password (Password Authentication) idp.admin.Hello (Hello World) ...
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505085/AuthenticationConfiguration
The primary means of configuring authentication, and particular login flows, is via the file authn/authn.properties. Most of the settings in this file are commented out and defaulted, so setting the ones you need generally involves uncommenting them
Essentially, any bean property that used to be settable via the (now legacy) general-authn.xml file are typically settable now with a property.
The overall list of enabled flows is controlled using the idp.authn.flows property that expresses the flows to enable as a regular expression (usually of the form “Method1|Method2|Method3”). Any flow not enabled will be ignored, except in the case of direct use from within the MFA flow.
Since V4.1, the use of XML to configure many basic features has been minimized and replaced by simpler properties, with a new file (authn/authn.properties)
A handful of authentication-related properties that were in idp.properties in older releases have been moved to the new authn.properties file in this version for better locality of reference
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505587/PasswordAuthnConfiguration
The auth n/Password login flow supports an extensible set of back-ends for password-based authentication, normally collected using a web form, and is the flow used at least in part by most deployments.
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199505688/LDAPAuthnConfiguration
The LDAPCredentialValidator for the password authentication login flow uses native LDAP libraries for password-based authentication instead of using a JAAS module. The primary advantages are slightly better performance and more control over the process, such as the ability to extract detailed account status information from the directory during a login.
Configuring LDAP as a back-end relies on beans internally that are configured using ldap.properties (defined separately from other properties because they are sometimes shared for LDAPConnector configuration).:
fichiers de conf a modifier
[root@idp5 conf]# cp authn/authn.properties authn/authn.properties.orig [root@idp5 conf]# cp ldap.properties ldap.properties.orig
idp.authn.LDAP.bindDNCredential ⇒ Password to bind with during search, used by bindSearchAuthenticator, usually set via %{idp.home}/credentials/secrets.properties
[root@idp5 conf]# cp ../credentials/secrets.properties ../credentials/secrets.properties.orig [root@idp5 conf]# vim ../credentials/secrets.properties
The Shibboleth IdP generally requires SAML metadata to provision connectivity with SAML relying parties and inform it about their capabilities and technical specifics
you will configure metadata sources in order to use the IdP's SAML features; this is done by adding <MetadataProvider> elements inside the metadata-providers.xml file.
[root@idp5 conf]# cp metadata-providers.xml metadata-providers.xml.orig [root@idp5 conf]# vim metadata-providers.xml