Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Numbered Headings


Apache HTTPD is generally compatible with Moonshot through the use of an Apache GSS-API module.



In the tables below, the following icons have the following meanings:

  • (tick) - This version of the software has been tested and verified as supporting Moonshot.
  • (error) - This version of the software has been tested and verified as not supporting Moonshot.
  • (question) - This version of the software has not yet been tested thoroughly and its status is not known. Let us know if you have tried it and whether it worked or not!

Compatibility List

Note that accessing supported versions of this software requires a Moonshot compatible client - see the next section for details on which clients are supported.


Any versions not listed below have not yet been tested. If you do so, please let us know!

Apache 2.4(tick)Using both the Moonshot and the RedHat GSSAPI mod_auth_gssapi modules
Apache 2.2(tick)Using the Moonshot mod_auth_gssapi module
Apache 2.0(question) 
Apache 1.3(question) 

Installation & Configuration

How you set up a Moonshot-enabled version of the Apache HTTP server will differ depending on your OS. See the relevant pages for your particular distribution:

Instructions for building the module manually for RHEL-based platforms can be found here.

Client Compatibility

The following clients are known to work with this server software using Moonshot authentication (click on the link to see further information about enabling Moonshot in that client):

Next Steps

Once you have installed the software, what happens next?

Account Mapping

To Come


The simplest way to test the Apache Moonshot integration is to create a simple script, protected by Moonshot. To do this, do the following:

  1. Create a simple script to protect by creating a directory for cgi scripts.

    Code Block
    $ mkdir /var/www/moonshot
  2. Create a script in that directory called "hello.cgi" with the following content:

    Code Block
    # disable filename globbing
    set -f
    echo Content-type: text/plain
    echo "Hello $REMOTE_USER, you have successfully authenticated."
    echo "If an identifier is not displayed after Hello, but you can see this page, then your IdP is not releasing the AAA User-Name attribute to this service and you are anonymous."
    echo "Some information about your server:"
    echo PATH_INFO = "$PATH_INFO"
  3. Set the permissions appropriately:

    Code Block
    $ chown -R www-data /var/www/moonshot && chmod 755 /var/www/moonshot/hello.cgi
  4. Configure Apache to protect this location, by creating a file at /etc/apache2/conf.d/moonshot.conf with the following content:

    Code Block
    <Directory "/var/www/moonshot/">
        AuthType Negotiate
        Require valid-user
        AddHandler cgi-script .cgi
        Options +ExecCGI
  5. Restart Apache2

    Code Block
    $ service apache2 restart
  6. Test by browsing to http://$yourservername/moonshot/hello.cgi with a compatible browser.


Incompatibility with other Apache modules

Currently there exist a problem of incompatibility when using Moonshot with other Apache modules, such as mod_shib or mod_php. The reason seems to be that Apache modules are dynamically loaded using the RTLD_GLOBAL flag. This makes that then causes duplicated symbol names are to be overwritten in memory, resulting into in calls to the wrong symbol and , thus , segmantation segmentation faults.

One of the symptoms of this incompatibility is text similar to the below in the Apache error log (error_log):

Code Block
titleerror_log entry
[date time] [error] [client] Failed to establish authentication: Invalid token was supplied (Unknown error)
[date time] [notice] child pid 12345 exit signal Segmentation fault (11)

Apache developers acknowledge this bug in the documentation of apr_dso_load (

We aught to provide an alternative to RTLD_GLOBAL, which is the only supported method of loading DSOs today.

In particular, we have detected problems with (at least) the following modules:

  • mod_shib Shibboleth module.
    This module is currently not compatible with the Shibboleth2 service provider Apache module. The reason is that mod_shib makes use of, whereas Moonshot makes use of As both libraries provide symbols with the same name but different implementations the system gets confused and fails.
    To resolve this error, just disable the Shibboleth module.
  • mod_php5 JSON submodule.
    This module is not compatible with the PHP5 JSON submodule. The reason is that the module is built with whereas Moonshot is built with Both libraries share symbol names that fail when Apache dynamically loads them.
    To resolve this error, disable the PHP5 JSON submodule. In Debian, just delete the /etc/php5/apache2/conf.d/20-json.ini file. Note that no JSON support will be available from PHP.

Another alternative (and preferred) way of work-around this issues is to manually patch libapr to force the usage of the RTDL_DEEPBIND flag (as suggested by the developers in In such a case, you need to ensure that the locally installed library is chosen before the system's one. The APR libray can be downloaded from


In order to co-exist with the Shibboleth module, you should use the following option:

Code Block
ShibCompatValidUser On

The Shibboleth documentation say that:

Code Block
# Turn this on to support "require valid-user" rules from other
# mod_authn_* modules, and use "require shib-session" for anonymous
# session-based authorization in mod_shib.


RP Proxy configuration

Populating REMOTE_USER

Web services often rely on the REMOTE_USER Apache environment variable for user information, such as a local user account or a pseudonymous identifier.

To populate REMOTE_USER, update the reply from the RP Proxy with the User-Name RADIUS attribute in the RP Proxy's post-auth section:

Code Block
if (&request:GSS-Acceptor-Service-Name != 'trustidentity') {
    update reply {
        User-Name := "content"

Setting the GSS-Acceptor-Host-Name and GSS-Acceptor-Service-Name attributes

You may find during testing that you get failures when attempting to authenticate. Run the RP Proxy in debug mode and check the incoming access requests from your webserver. When an access request looks similar to the below, you will notice that the GSS-Acceptor-Host-Name and/or GSS-Acceptor-Service-Name attributes are not set correctly, or are missing altogether, and you must set them manually.

Code Block
(0) Sent Access-Request Id 1 from to length 128
(0)   User-Name = ''
(0)   EAP-Message = 0x02...
(0)   Message-Authenticator = 0x...
(0)   Trust-Router-COI := ''
(0)   GSS-Acceptor-Realm-Name := ''
(0)   Event-Timestamp = 'Jan 20 2017 10:20:28 GMT'
(0)   NAS-IP-Address =
(0)   Proxy-State = 0x30

To set these two vital attributes, you must do the following in your RP Proxy configuration:

  1. Open the sites-available/abfab-tls file in the FreeRADIUS configuration directory (on RHEL platforms, it's /etc/raddb, on Debian platforms it's /etc/freeradius).
  2. Locate the line 'clients radsec-abfab'.
  3. Duplicate the 'client default' block below it and modify the duplicate to suit the requirements as below, then save the file:

    Code Block
        client moonshot-webserver-name {
            ipaddr = ipaddress of the webserver
            proto = tls
            gss_acceptor_host_name = "the actual hostname of the webserver, i.e."
            gss_acceptor_service_name = "HTTP"
            gss_acceptor_realm_name	= "the same realm name as in the 'client default' block"
            trust_router_coi = "the same realm name as in the 'client default' block"

    You can name the client in the block above anything from just a simple entry to its full hostname. To make things easier, you may use the shortname configuration option in the list of options to set a short name that you can use elsewhere in your FreeRADIUS configuration.

    The ipaddr configuration option also accepts CIDR-formatted IP address blocks if you have multiple servers you want to connect as the same host.

  4. Open the sites-available/abfab-tr-idp file in the FreeRADIUS configuration directory (on RHEL platforms, it's /etc/raddb, on Debian platforms it's /etc/freeradius).
  5. Locate the line 'psk_authorize'. Insert the following block before that line, then save the file:

    Code Block
    if ("%{client:gss_acceptor_host_name}") {
        update request {
            GSS-Acceptor-Host-Name = "%{client:gss_acceptor_host_name}"
    if ("%{client:gss_acceptor_service_name}") {
        update request {
            GSS-Acceptor-Service-Name = "%{client:gss_acceptor_service_name}"

    This issue should be rectified and no longer necessary from FreeRADIUS 3.0.13 onwards.

  6. Restart your RP Proxy, and re-test. Your entry should now look something more like this:

    Code Block
    (0) Sent Access-Request Id 10 from to length 159
    (0)   User-Name = ''
    (0)   GSS-Acceptor-Service-Name = 'HTTP'
    (0)   GSS-Acceptor-Host-Name = ''
    (0)   EAP-Message = 0x02...
    (0)   Message-Authenticator = 0x2a8cf41456b3b2e94473a1eb2849e561
    (0)   Trust-Router-COI := ''
    (0)   GSS-Acceptor-Realm-Name := ''
    (0)   Event-Timestamp = 'Jan 20 2017 10:34:18 GMT'
    (0)   NAS-IP-Address =
    (0)   Proxy-State = 0x30

AppArmor and SELinux

Ubuntu's AppArmor and the RedHat SELinux systems are also known to interfere with Apache's loading of the Moonshot module. Follow the appropriate operating system's instructions on how to allow Apache to access files outside its assigned directories.