Page tree

Versions Compared

Key

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

...

Numbered Headings

Include Page
TEM:_SystemPrep_ALPINE
TEM:_SystemPrep_ALPINE

Install the Moonshot IdP

Warning
titleAlpine < 3.9 not supported

Prior version 3.9, Alpine Linux was built using libressl instead of openssl. Although both are generally compatible, libressl lacks of support for TLS PSK, which is a cornerstone of the trust router infrastructure. Therefore, versions < 3.9 are unsupported.


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

Code Block
languagebash
linenumberstrue
apk add moonshot trust_router freeradius-abfab

Configure the Moonshot IdP

Next, we need to configure the Moonshot IdP.

Configure FreeRADIUS

Include Page
TEM:_CertPrep_ALPINE
TEM:_CertPrep_ALPINE

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/raddb/proxy.conf:
    1. Add the following at the bottom of the file, where YOUR_REALM should be substituted by your realm (e.g. camford.ac.uk):

      Code Block
      linenumberstrue
      realm YOUR_REALM {
      	# Intentionally left blank
      }


Channel Binding Support

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

  1. Open /etc/raddb/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:

      Code Block
      client default {
              ipaddr = 0.0.0.0/0
              proto = tls
              gss_acceptor_realm_name = "your IDP realm here"
              trust_router_coi = ov-apc.moonshot.ja.net
      }


      Note
      titlegss_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.


    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/raddb/mods-enabled/eap. Find the first instance of default_eap_type = md5 and change it to TTLS. 

    Code Block
    default_eap_type = 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.

Tip

To see the full range of options available, and find out how to configure them, visit the FreeRADIUS site.

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/raddb/users for editing and put the following at the top of the file

    Code Block
    linenumberstrue
    testuser	Cleartext-Password := "testing"
    			Reply-Message = "Hello test user. You have authenticated!"


    Warning

    The formatting of the stanza above is very important. There should be a line break 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.

Include Page
TEM:_TIDC_FR_Prep_ALPINE
TEM:_TIDC_FR_Prep_ALPINE

Configure TIDS

TBD

Testing

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

Tip
titleTip

At this point you probably want three consoles open on the server, so that you can manually run various components separately.

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 radiusd user):

    Code Block
    languagebash
    linenumberstrue
    su --shell=/bin/bash radius
    radiusd -fxx -l stdout


  2. Check that no errors are output.

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

    Code Block
    languagebash
    linenumberstrue
    radtest testuser@YOURREALM testing 127.0.0.1:18120 2222 testing123


    Info

    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:

    Code Block
    titleIn window 1 - FreeRADIUS server output
    Sending Access-Accept of id 57 from 127.0.0.1 port 18120 to 127.0.0.1 port 33363
         Reply-Message = 'Hello test user. You have authenticated!'
    (1) Finished request 1.
    Waking up in 0.3 seconds.
    Waking up in 4.6 seconds.
    (1) Cleaning up request packet ID 57 with timestamp +94
    Ready to process requests.


    Code Block
    titleIn window 2 - radtest client output
    Sending Access-Request of id 57 from 0.0.0.0 port 33363 to 127.0.0.1 port 18120
         User-Name = 'testuser'
         User-Password = 'testing'
         NAS-IP-Address = 127.0.1.1
         NAS-Port = 2222
         Message-Authenticator = 0x00
    rad_recv: Access-Accept packet from host 127.0.0.1 port 18120, id=57, length=61
         Reply-Message = 'Hello test user. You have authenticated!'


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 radiusd user) run the tidc command:

    Code Block
    languagebash
    linenumberstrue
    su - --shell=/bin/bash radius
    tidc tr.moonshot.ja.net [your rp-realm] ov-apc.moonshot.ja.net ov-apc.moonshot.ja.net


    Info

    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:

    Code Block
    titleIn window 2 - TIDC output
    TIDC Client:
    Server = tr.moonshot.ja.net, rp_realm = moonshot-idp.camford.ac.uk, target_realm = ov-apc.moonshot.ja.net, community = ov-apc.moonshot.ja.net
    connecting to host 'tr.moonshot.ja.net' on port 12309
    CTRL-EVENT-EAP-STARTED EAP authentication started
    CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
    CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
    CTRL-EVENT-EAP-PEER-CERT [...]
    CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
    tidc_fwd_request: Sending TID request:
    
    [...]
    
    tr_msg_decode_tidresp(): Success! result = success.
    tr_msg_decode_servers(): Number of servers = 1.
    Response received! Realm = ov-apc.moonshot.ja.net, Community = ov-apc.moonshot.ja.net.
    Client Key Generated (len = 256):
    
    [...]


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:

    Code Block
    languagebash
    linenumberstrue
    su - --shell=/bin/bash trustrouter
    tids --ip [your server IP] --hostname [your server hostname] trustrouter@ov-apc.moonshot.ja.net 

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

    Note

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


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

    Code Block
    languagebash
    linenumberstrue
    su - --shell=/bin/bash radius
    tidc tr.moonshot.ja.net [your rp-realm] [YOUR_REALM] ov-apc.moonshot.ja.net


    Info

    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.6] [apc-name]


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

    Code Block
    titleIn window 2 - TIDC output
    TIDC Client:
    Server = tr.moonshot.ja.net, rp_realm = moonshot-idp.camford.ac.uk, target_realm = camford.ac.uk, community = ov-apc.moonshot.ja.net
    connecting to host 'tr.moonshot.ja.net' on port 12309
    CTRL-EVENT-EAP-STARTED EAP authentication started
    CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
    CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
    CTRL-EVENT-EAP-PEER-CERT [...]
    CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
    tidc_fwd_request: Sending TID request:
    
    [...]
    
    tr_msg_decode_tidresp(): Success! result = success.
    tr_msg_decode_servers(): Number of servers = 1.
    Response received! Realm = camford.ac.uk, Community = ov-apc.moonshot.ja.net.
    Client Key Generated (len = 256):
    
    [...]

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

    Code Block
    titleIn window 1 - FreeRADIUS output
    (9) Found Auth-Type = Accept
    (9) Auth-Type = Accept, accepting the user
    (9) # Executing section post-auth from file /etc/raddb/sites-enabled/abfab-tr-idp
    (9)   post-auth {
    (9)     [exec] = noop
    (9)     policy remove_reply_message_if_eap {
    (9)       if (&reply:EAP-Message && &reply:Reply-Message) {
    (9)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
    (9)       else {
    (9)         [noop] = noop
    (9)       } # else = noop
    (9)     } # policy remove_reply_message_if_eap = noop
    (9)   } # post-auth = noop
    (9) Sent Access-Accept Id 0 from 0.0.0.0:2083 to 127.0.0.1:56352 length 196
    (9)   Message-Authenticator = 0x856c08f200d29d641e486a1ccc48799a
    (9)   User-Name = 'trustrouter@ov-apc.moonshot.ja.net'
    (9)   MS-MPPE-Recv-Key = 0xac76ebd3df5fd9f11b57ad0fbc57b92175a8c8f7b4f3ae18bc4ccab5184e6158
    (9)   MS-MPPE-Send-Key = 0xb891112bc014a06dbbeb8170d64136d2e0359a0c255d846fb5772f2733205782
    (9)   EAP-Message = 0x03090004
    (9) Finished request
    Closing TLS socket from client port 56352
    (0) >>> TLS 1.0 Alert [length 0002], warning close_notify
    Client has closed connection
    Waking up in 3.7 seconds.
    (0) <done>: Cleaning up request packet ID 0 with timestamp +25


  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

This is not supported for Alpine at the moment.

You must run the tids and radisud applications manually as described above.

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 Configuring FreeRADIUS to Use a Local Identity Store 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 Issue SAML Assertions 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 Configure the Moonshot RP Proxy to Talk to Applications/Services page.


...