Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Fix link

...

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:

  1. Use the setuid extension to support listening on the privileged ports as a non-root user.

  2. Use a port forwarding approach (load balancer, iptables rules, etc).

  3. 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.

  1. 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

  2. We provide a backchannel module to control the feature and turn it on or off.

  3. 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
    
  4. 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.

...