Install the Moonshot IdP

We’re now ready to install the Moonshot software and its required dependencies. Install the software by running the following command:

There is a bug (https://bugs.launchpad.net/moonshot-tr/+bug/1619782) that precludes moonshot-trust-router package from being installed. A workaround consists on creating an empty /etc/default/trust_router file (that will be updated later following Section 3.1's instructions) and trying again the apt-get install command above.

Configure the Moonshot IdP

Next, we need to configure the Moonshot IdP.

Configure FreeRADIUS

Moonshot UI credential store

We need to enable the freeradius user to use the Moonshot UI flatstore:

Set up the FreeRADIUS and Trust Router users

To allow FreeRADIUS to read a key database for dynamic realm support, we need to place the FreeRADIUS user and the Trust Router users into each other's groups to allow them to read shared files of each other.

RadSec

Next, we need to configure RadSec. We do this by creating a file at /etc/radsec.conf with the following:

Dynamic Realm support

We need to tell your FreeRADIUS server to support dynamic lookup of realms.

1. Open /etc/freeradius/proxy.conf for editing:
   1. Towards the top of the file is a stanza beginning "proxy server {". Find this.

   2. Below this, add dynamic = yes, like so:

      true

      
      

Realm

We need to configure your realm in the FreeRADIUS server so that it knows not to send any requests for your own users off to another server.

1. Configure your realm in /etc/freeradius/proxy.conf:
   1. Open the file for editing and find the line realm example.com {

   2. Above this, add the following, where YOUR_REALM should be substituted by your realm (e.g. camford.ac.uk):

      true

      
      

Channel Binding Support

We need to configure your FreeRADIUS server to support channel bindings.

1. Open /etc/freeradius/sites-available/abfab-tls for editing:
   1. Scroll to the client default stanza at the bottom of the file

   2. Edit the stanza to match the below:

      
      

      gss_acceptor_realm_name

      Specify the same RP realm as in the rp_realm option in Section 4.1 below. For simple IdP deployments, this usually matches your IDP Realm. When running a mixed IdP-RP Proxy deployment, follow the advice for an RP Proxy.

      Additionally, you must add a domain wildcard constraint in the Jisc Assent Portal that will match this realm value.

      
      

   3. If you have any other client definitions here, for example to distinguish between internal and external clients, also apply the change to them.

EAP Type

1. Set the EAP type in use by moonshot (EAP-TTLS) by editing /etc/freeradius/mods-enabled/eap. Find the first instance of default_eap_type = md5 and change it to TTLS.

User Authentication

FreeRADIUS offers many options on to authenticate users; common ones including using a simple local flat file (useful for initial testing), or for production deployments using a credential store in an SQL database or a connection to LDAP/AD.

For the purposes of initial testing, we will use a simple local flat file, creating a user with username "testuser" and password "testing".

1. Open /etc/freeradius/users for editing and put the following at the top of the file

   true

   
   

   The formatting of the stanza above is very important. There should be a <tab> in between the username and Cleartext-Password, and a line break followed by a <tab> before the Reply-Message.

   
   

Configure the Trust Router Client

If you are going to connect your Moonshot IdP to a Trust Router network, then the next step involves configuring the Trust Router client software and configuring its connection to a Trust Router.

Configure TIDS

The IdP also runs the Temporary ID Server (TIDS).

1. Open the /etc/default/trust_router file for editing. If necessary, create it.

   true

   
   

Testing

Now that we have the Moonshot IdP installed and configured, we're now ready to test!

Testing FreeRADIUS locally

The first test is to check whether FreeRADIUS is working in its most basic manner.

1. In window 1, run (as the freerad user)

   bash

   
   

2. Check that no errors are output.

3. In window 2, run (as root user)

   bash

   
   

   This uses the "radtest" utility which is used in the following way - radtest username password servername port shared-secret

   
   

4. If this is working correctly you should see something like the following:

   In window 1 - FreeRADIUS server output

   
   

   In window 2 - radtest client output

   
   

Testing the Trust Router connection

To test the connection to Trust Router, we need to make sure the Temporary Identity Server (TIDS) software is running, then use the Temporary Identity Client (TIDC) software to simulate a connection to the Trust Router.

Testing using the Temporary Identity Client (TIDC)

1. In window 2, (as the freerad user) run the tidc command:

   bash

   
   

   This uses the "tidc" binary which is used in the following way - tidc [hostname-of-trust-router] [rp-realm] [hostname-of-apc-server] [apc-name]

   
   

2. If the Trust Router connection was successful, you should see something like the following:

   In window 2 - TIDC output

   
   

Testing the Temporary Identity Server (TIDS)

1. In window 3 (as the trustrouter user, window 1 should still be still running the FreeRADIUS server and window 2 the TIDC command), run the TIDS software:

   bash

   trustrouter@ov-apc.moonshot.ja.net is the identity that the trust router will use when provisioning keys - this makes it easy to spot in your own log files.
   Specifying your server's IP and hostname may seem redundant (and for single server deployments, it is!). You'll need to set the hostname and IP arguments a little differently if you want to enable some more advanced configurations (such as load balancing and key sharing).

   This uses the "tids" binary which is used in the following way - tids [your-ip-address] trustrouter-gss-name] [your-hostname] [path-to-key-database]

   
   

   When using Network Address Translation (NAT) or a firewall, you must specify your external IP address.

   
   

2. In window 2, (as the freerad user) run the tidc command again, but this time modify it slightly and specifying the realm you defined in Section 3.1.5 above:

   bash

   
   

   This uses the "tidc" binary which is used in the following way - tidc [hostname-of-trust-router] [rp-realm] [identity realm specified in Section 3.1.5] [apc-name]

   
   

3. If the Trust Router connection was successful, you should see something like the following:

   In window 2 - TIDC output

   Additionally, in window 1, where FreeRADIUS is running, you should see something similar to this:

   In window 1 - FreeRADIUS output

   
   

4. With the tests successful, you can now terminate the FreeRADIUS (window 1) and TIDS (window 3) processes.

Next Steps

At this point, you now have a Moonshot IdP that is working and registered with a Trust Router. Now for the next steps:

Automatically start the software

FreeRADIUS

To automatically start FreeRADIUS, issue the following command (as root):

If this is working correctly, you should see FreeRADIUS running as a daemon process.

TIDS

To automatically start TIDS, issue the following command (as root):

If this is working correctly, you should see TIDS running as a daemon process.

Configure a real source of Authentication

Your FreeRADIUS server can currently only authenticate a single user - "testuser". At this point, you will want to connect to Active Directory, LDAP, an SQL database, or some other source of credentials.

See for more information and instructions for how to do this.

Integrate SAML

As currently configured, this Moonshot IdP can only use RADIUS attributes. If you wish to also include SAML assertions, visit the page to see the options available to you.

Configure clients

If you are going to also use your Moonshot IdP as a Moonshot RP (i.e., connect services to it that you wish to allow people to authenticate to using Moonshot), then see the page.