Date: Fri, 29 Mar 2024 02:26:29 +0000 (UTC) Message-ID: <2047272789.9.1711679189079@27e03f5c4044> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8_963891326.1711679189079" ------=_Part_8_963891326.1711679189079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
JAVA_OPTS
environment =
variable (all ### is the amount of memory in megabytes to allow for the opt=
ion):
maxPostSize attribute. A size of about 100K (100000) is a reasonable choice.
Most new deployments without legacy needs will not need to support back-= channel SOAP communication. The most common case requiring this feature is = support for legacy Shibboleth SPs using SAML 1.1 that perform attribute que= ries using SOAP.
If you do need this support, these connections require special security = properties which are not appropriate for user-facing/browser use. Therefore= an additional endpoint must be configured.
For Tomcat 6, download tomcat6-dta-ssl-1.1= .0.jar (asc) in to TOMC= AT_HOME/lib/, or to use Tomcat= 7 with the unofficial Unicon component, download tomcat7-1.1.jar.
Add the following connector definition to Tomcat's TOMCAT_HOME/conf/= server.xml file for tomcat 6:
<Conn= ector port=3D"8443" protocol=3D"org.apache.coyote.http11.Http11Protocol" SSLImplementation=3D"edu.internet2.middleware.security.tomcat6.D= elegateToApplicationJSSEImplementation" scheme=3D"https" maxPostSize=3D"100000" SSLEnabled=3D"true" clientAuth=3D"want" keystoreFile=3D"IDP_HOME/credentials/idp.jks" keystorePass=3D"PASSWORD" />
or this one for tomcat 7:
<= ;Connector port=3D"8443" protocol=3D"org.apache.coyote.http11.Http11Protocol" sslImplementationName=3D"edu.internet2.middleware.security.t= omcat7.DelegateToApplicationJSSEImplementation" SSLEnabled=3D"true" scheme=3D"https" secure=3D"true" maxPostSize=3D"100000" clientAuth=3D"want" keystoreFile=3D"IDP_HOME/credentials/idp.jks" keystorePass=3D"PASSWORD" sslProtocol=3D"TLS" />
IDP_HOME
with the IdP home directory entered durin=
g installation.PASSWORD
with the password for the IdP key entered=
during installation.If you use this deployment method you do not need to do anything additio= nal to deploy your application.
Normally you deploy web applications to Tomcat by copying the WAR file i=
nto the Tomcat webapps/
. However, when you do this Tomcat will=
explode the war (giving you idp.war and idp/
within =
webapps/
) and then cache another version of the application in=
work/Catalina/localhost/
. This can lead to cases where you co=
py a new WAR into place but Tomcat continues to use the older version.
To address this, it is recommended that you use a context deployment fra=
gment, which is just a small bit of XML that tells Tomcat where to get the =
WAR and provides some properties used when Tomcat load the application. Thi=
s approach will also prevent those times when you create a new WAR and forg=
et to copy it into Tomcat as this makes Tomcat load the war from IDP_=
HOME/war/
where the installer places it.
Create the file TOMCAT_HOME/conf/Catalina/localhost/idp.xml
=
and place the following content in it (replacing IDP_HOME
wit=
h your IdP's home directory):
<Con= text docBase=3D"IDP_HOME/war/idp.war" privileged=3D"true" antiResourceLocking=3D"false" antiJARLocking=3D"false" unpackWAR=3D"false" swallowOutput=3D"true" />
You might also want to add cookies=3D"false"
to the ab=
ove Context Deployment Fragment, to prevent Tomcat from settting HTTP Cooki=
es e.g. on MDUI Logos hosted at th=
e IdP webserver, which would trigger Third Party Cookie warnings in some HT=
TP User Agents.