...
One challenge remains that if you want to use standard ports, you would need to pick one of these options to avoid running as root:
Use the setuid extension to support listening on the privileged ports as a non-root user.
Use a port forwarding approach (load balancer, iptables rules, etc).
Use POSIX capabilities to allow use of priviledged ports by an unpriviledged process, e.g. when using systemd by setting
AmbientCapabilities=CAP_NET_BIND_SERVICE
idp.ini
Code Block |
---|
# --------------------------------------- # Module: idp # Shibboleth IdP # --------------------------------------- --module=idp ## Keystore file path (relative to $jetty.base) jetty.sslContext.keyStorePath=../credentials/idp-userfacing.p12 ## Truststore file path (relative to $jetty.base) jetty.sslContext.trustStorePath=../credentials/idp-userfacing.p12 ## Keystore type jetty.sslContext.keyStoreType=PKCS12 ## Truststore type and provider jetty.sslContext.trustStoreType=PKCS12 ## Keystore password jetty.sslContext.keyStorePassword=changeit ## Truststore password jetty.sslContext.trustStorePassword=changeit ## KeyManager password jetty.sslContext.keyManagerPassword=changeit ## Deny SSL renegotiation jetty.sslContext.renegotiationAllowed=false ## Connector host/address to bind to # jetty.ssl.host=0.0.0.0 ## Connector port to listen on jetty.ssl.port=443 # Allows use of default IdP command line tools. jetty.http.host=127.0.0.1 jetty.http.port=80 |
...
Note |
---|
The use of the back-channel is discussed in the SecurityAndNetworking topic, and you should review that to understand whether or not you need to support this feature. You very likely don’t, and if you do, it’s worth exploring steps you might take to get out of needing it. The IdP fully supports all of the necessary features to secure requests made to the regular port using signed messages. |
If you do need this support, these connections generally require special security properties that are not appropriate for user-facing/browser use. Therefore an additional endpoint must be configured.
The jetty94-dta-ssl-1.0.0.jar (asc) plugin (the name hasn’t changed because Jetty 10 supports the same extension API) can be placed in JETTY_BASE/lib/ext
We provide a backchannel module to control the feature and turn it on or off.
Adjust JETTY_BASE/start.d/idp-backchannel.ini as required:
Code Block # --------------------------------------- # Module: idp-backchannel # Shibboleth IdP Dedicated SOAP Connector # --------------------------------------- --module=idp-backchannel ## Backchannel connector port to listen on # idp.backchannel.port=8443 ## Backchannel keystore file path (relative to $jetty.base) # idp.backchannel.keyStorePath=../credentials/idp-backchannel.p12 ## Backchannel keystore password # idp.backchannel.keyStorePassword=changeit ## Backchannel keystore type # idp.backchannel.keyStoreType=PKCS12
Modify JETTY_BASE/etc/idp-backchannel.xml if desired. You get more control over the TLS settings if you need them, but normally this file is just used to plug in the properties we support from the ini file.
Other Modules
Jetty has a ton of advanced and optional functionality available in the form of modules that can be enabled selectively. They don't function in the way Apache modules do, but they're basically packaged "example" configuration files that will get copied from JETTY_HOME
into JETTY_BASE
when you need them and you get "just" the minimum files needed to support the feature but keep future upgrades simple.
...