Install an IdP on Alpine Linux
On this page you will find instructions on how to set up a Moonshot Identity Provider (IdP) on Alpine Linux. It also installs and configures the Trust Router client, if you are going to use the Trust Router infrastructure.
Contents
System Preparation
Install Alpine Linux
The first thing that is required is an Alpine Linux machine - this can be physical, virtual or a container.
Tip
We would recommend using LVM when disk partitioning to allow easier partition/disk expansion on a live system.
Warning
After install, you will want to secure/lockdown the server as best practice dictates - for both the server and any extra software installed. This is beyond the remit of this guide but there are many guides available that provide information on how to secure your Alpine servers and applications.
Configure Alpine
Next, there are a few Alpine configuration options that need to be set in advance:
Networking configuration
For production deployments, it is recommended that the machine be assigned a static IP address.
Firewall configuration
The following ports are required to be accessible from the outside world, both in the local firewall and in any external firewalls:
- 2083/tcp (for RadSec connections to other Moonshot entities)
- 12309/tcp (for Trust Router client connections - if using the Trust Router to broker trust relationships between entities)
Here are sample firewall rules that establish incoming and outgoing rules to both the Test and Live (Jisc Assent) Moonshot trust router infrastructures. If you connect to another Trust Router, adjust these rules to suit:
IP Tables sample firewall rules (Jisc Assent)
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s 0/0 --dst <IdP/RP Proxy IP address> --dport 2083 -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s <IdP/RP Proxy IP address> --dst 0/0 --dport 2083 -j ACCEPT
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s 212.219.179.130,212.219.179.131,212.219.179.138,212.219.179.146 --dst <IdP/RP Proxy IP address> --dport 12309 -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s <IdP/RP Proxy IP address> --dst 212.219.179.130,212.219.179.131,212.219.179.138,212.219.179.146 --dport 12309 -j ACCEPT
IP Tables sample firewall rules (Test Network)
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s 0/0 --dst <IdP/RP Proxy IP address> --dport 2083 -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s <IdP/RP Proxy IP address> --dst 0/0 --dport 2083 -j ACCEPT
-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s 13.79.134.211,13.79.128.103,52.169.31.104 --dst <IdP/RP Proxy IP address> --dport 12309 -j ACCEPT
-A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp -s <IdP/RP Proxy IP address> --dst 13.79.134.211,13.79.128.103,52.169.31.104 --dport 12309 -j ACCEPT
Add the Required Repositories
Supported versions
At the moment, Alpine 3.11 and Alpine 3.13 (x86_64 and armhf) are supported.
Add the Moonshot Alpine repository to your system. To do this, run the following command (as root, or using sudo):
Install the Moonshot repository RSA key.
curl "https://repository.project-moonshot.org/alpine/moonshot@jisc.ac.uk-5be46530.rsa.pub" > /etc/apk/keys/moonshot@jisc.ac.uk-5be46530.rsa.pub
1. 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:
apk add moonshot trust_router freeradius-abfab freeradius-radclient
2. Configure the Moonshot IdP
Next, we need to configure the Moonshot IdP.
2.1. Configure FreeRADIUS
Certificates
We need to get FreeRADIUS to create some private and public keys to use for its RadSec connections. Create and install the certificates by doing the following (as root).
Change into the
/etc/raddb/certs
directorycd /etc/raddb/certs
Edit the certificate generation properties in client.cnf, server.cnf, and ca.cnf as follows:
- In the
ca.cnf
file:- In the
[ req ]
section, addencrypt_key = no
In the
[CA_default]
section, change the default_days from 60 to a higher number (this is how long the certificates you create will be valid for). When the certificates expire, you will have to recreate them.in the
[ certificate_authority ]
section, change all of the parameters to match those of your organisation. e.g.[certificate_authority] countryName = GB stateOrProvinceName = England localityName = Camford organizationName = Camford University emailAddress = support@camford.ac.uk commonName = "Camford University FR Certificate Authority"
- In the
In the
server.cnf
file:- In the
[ req ]
section, addencrypt_key = no
- In the
[CA_default]
section, change the default_days from 60 to a higher number (this is how long the certificates you create will be valid for). When the certificates expire, you will have to recreate them. in the
[ server ]
section, change all of the parameters to match those of your organisation. e.g.[server] countryName = GB stateOrProvinceName = England localityName = Camford organizationName = Camford University emailAddress = support@camford.ac.uk commonName = "Camford University FR Server Certificate"
When changing passwords in the
[ req ]
section of the server.cnf file, you must also update theprivate_key_password
option in the FreeRADIUSmods-available/eap
file with the same password.We recommend that you do not change these defaults.
- In the
In the
client.cnf
file:- In the
[ req ]
section, addencrypt_key = no
- In the
[CA_default]
section, change the default_days from 60 to a higher number (this is how long the certificates you create will be valid for). When the certificates expire, you will have to recreate them. in the
[ client ]
section, change all of the parameters to match those of your organisation. e.g.[client] countryName = GB stateOrProvinceName = England localityName = Camford organizationName = Camford University emailAddress = support@camford.ac.uk commonName = "Camford University FR Client Certificate"
All of the organisation parameters (countryName
,localityName
, etc) need to match in the three .cnf files but thecommonName
must be unique in each file)
- In the
- In the
Clear out any old certificates in the directory:
make destroycerts
Run the bootstrap script to generate the certificates
./bootstrap
Create a file that is the concatenation of the certificate and private key of the client.
openssl x509 -in client.crt > client.pem ; cat client.key >> client.pem
Because the above command was run as root, the keys and certificates created will not be readable by the FreeRADIUS user by default, and FreeRADIUS will not be able to start. To fix this, reset the group for the files:
chgrp radius client* server* ca* dh*
RadSec
Next, we need to configure RadSec. We do this by creating a file at /etc/radsec.conf
with the following:
realm gss-eap { type = "TLS" cacertfile = "/etc/raddb/certs/ca.pem" certfile = "/etc/raddb/certs/client.pem" certkeyfile = "/etc/raddb/certs/client.key" disable_hostname_check = yes server { hostname = "127.0.0.1" service = "2083" secret = "radsec" } }
Dynamic Realm support
We need to tell your FreeRADIUS server to support dynamic lookup of realms.
- Open
/etc/raddb/proxy.conf
for editing:- Towards the top of the file is a stanza beginning "
proxy server {
". Find this. Below this, add
dynamic = yes
, like so:proxy server { dynamic = yes
- Towards the top of the file is a stanza beginning "
2.1.1. 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.
- Configure your realm in
/etc/raddb/proxy.conf
:Add the following at the bottom of the file, where YOUR_REALM should be substituted by your realm (e.g. camford.ac.uk):
realm YOUR_REALM { # Intentionally left blank }
2.1.2. Channel Binding Support
We need to configure your FreeRADIUS server to support channel bindings.
- Open
/etc/raddb/sites-available/abfab-tls
for editing:- Scroll to the
client default
stanza at the bottom of the file Edit the stanza to match the below:
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 }
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.- If you have any other client definitions here, for example to distinguish between internal and external clients, also apply the change to them.
- Scroll to the
2.1.3. EAP Type
Set the EAP type in use by moonshot (EAP-TTLS) by editing
/etc/raddb/mods-enabled/eap
. Find the first instance ofdefault_eap_type = md5
and change it to TTLS.default_eap_type = ttls
2.1.4. 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.
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".
Open
/etc/raddb/users
for editing and put the following at the top of the filetestuser Cleartext-Password := "testing" Reply-Message = "Hello test user. You have authenticated!"
The formatting of the stanza above is very important. There should be a line break before the Reply-Message.
3. 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 FreeRADIUS to use Trust Router
Configuring FreeRADIUS realm lookup
We need to configure the community and rp_realm appropriate for your Moonshot service, and the Trust Router that it will connect to.
- Open the
/etc/raddb/mods-enabled/realm
for editing. - Find the "realm suffix {" configuration directive, and fill out the fields as appropriate.
- Repeat this for the "realm bangpath {" configuration directive.
For the default Jisc Assent Trust Router this will look like the following:
realm suffix { format = suffix delimiter = "@" default_community = "ov-apc.moonshot.ja.net" rp_realm = "Your service realm as registered in the Jisc Assent Portal" trust_router = "tr.moonshot.ja.net" rekey_enabled = yes } realm bangpath { format = prefix delimiter = "!" default_community = "ov-apc.moonshot.ja.net" rp_realm = "Your service realm as registered in the Jisc Assent Portal" trust_router = "tr.moonshot.ja.net" rekey_enabled = yes }
Example
Camford University has a Moonshot service registered in the Jisc Assent Portal at the service realm of moonshot.camford.ac.uk, so its realm file would look like this:
realm suffix { format = suffix delimiter = "@" default_community = "ov-apc.moonshot.ja.net" rp_realm = "moonshot.camford.ac.uk" trust_router = "tr.moonshot.ja.net" rekey_enabled = yes } realm bangpath { format = prefix delimiter = "!" default_community = "ov-apc.moonshot.ja.net" rp_realm = "moonshot.camford.ac.uk" trust_router = "tr.moonshot.ja.net" rekey_enabled = yes }
Register your Trust Router client with a Trust Router
At this point, the Moonshot service needs to be associated with a Trust Router. To do this, you need to contact the operator of a Trust Router you wish to join for their specific instructions on how to do this.
Once you have joined the Trust Router service, you will be issued with an Organisation credential file in XML file format.
Jisc Assent service instructions
The below instructions are specific to the world's first Trust Router service, Jisc Assent, operated by Jisc in the United Kingdom:
- If you are not signed up to Assent, sign up to Assent first. This step may take a day or two while your organisation details are verified and you are invited to join the portal.
If you are signed up to Assent, log into the Assent portal and follow instructions on how to do it https://assent.jisc.ac.uk/help/organization#manage-credentials
- Download an Organisation credential under the 'Credential' section of your organisation in the portal (in the form of an XML file). Keep this file safe!
You must import the issued credential file using the
moonshot-webp
command as theradiusd
user:su - --shell=/bin/bash radius moonshot-webp -f [path to credential file]
Check that the credential has been correctly imported, by starting the UI and checking the credential has been correctly imported:
moonshot
- If the file exists, the credential file's contents should be present in the file.
3.1. Configure TIDS
The IdP also runs the Temporary ID Server (TIDS)
Open the
/etc/conf.d/tids
file for editing. If necessary, create it.ipaddr="[your server IP]" hostname="[your server hostname]" gssname="trustrouter@ov-apc.moonshot.ja.net"
4. Testing
Now that we have the Moonshot IdP installed and configured, we're now ready to test!
Tip
At this point you probably want three consoles open on the server, so that you can manually run various components separately.
4.1. Testing FreeRADIUS locally
The first test is to check whether FreeRADIUS is working in its most basic manner.
In window 1, run (as the radius user):
su -s /bin/sh radius radiusd -fxx -l stdout
Check that no errors are output.
In window 2, run (as root user)
radtest testuser@YOURREALM testing 127.0.0.1:18120 2222 testing123
This uses the "radtest" utility which is used in the following way - radtest username password servername port shared-secret
If this is working correctly you should see something like the following:
In window 1 - FreeRADIUS server outputSending 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.
In window 2 - radtest client outputSending 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!'
4.2. 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.
4.2.1. Testing using the Temporary Identity Client (TIDC)
In window 2, (as the radius user) run the tidc command:
su -s /bin/sh radius tidc tr.moonshot.ja.net [your rp-realm] ov-apc.moonshot.ja.net ov-apc.moonshot.ja.net
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]
If the Trust Router connection was successful, you should see something like the following:
In window 2 - TIDC outputTIDC 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): [...]
4.2.2. Testing the Temporary Identity Server (TIDS)
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:
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).When using Network Address Translation (NAT) or a firewall, you must specify your external IP address.
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:
su - --shell=/bin/bash radius tidc tr.moonshot.ja.net [your rp-realm] [YOUR_REALM] ov-apc.moonshot.ja.net
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]
If the Trust Router connection was successful, you should see something like the following:
In window 2 - TIDC outputTIDC 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:
In 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
- With the tests successful, you can now terminate the FreeRADIUS (window 1) and TIDS (window 3) processes.
5. 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:
5.1. Automatically start the software
5.1.1. FreeRADIUS
To automatically start FreeRADIUS, issue the following command (as root):
rc-update add radiusd rc-service radiusd start
If this is working correctly, you should see FreeRADIUS running as a daemon process.
5.1.2. TIDS
To automatically start TIDS, issue the following command (as root):
rc-update add tids rc-service tids start
If this is working correctly, you should see TIDS running as a daemon process.
5.2. 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.
5.3. 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.
5.4. 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.