In the meeting today, there were some questions about the instructions on the DevWiki and the Moonshot group. So I'll share what we (Diamond) have put together, which has given us a fairly stable reference implementation. JANET has this info also, it's just a matter of getting it online :-)
For CentOS, follow these instructions:
1. Configure LD_LIBRARY_PATH
LD_LIBRARY_PATH has to have /opt/moonshot/lib64/ and /usr/lib64/freeradius added to it.
The best way to do this is create a file at /etc/profile.d/moonshot.sh, with the following:
if [[ $LD_LIBRARY_PATH != */opt/moonshot/lib64/:/usr/lib64/freeradius/* ]]
then
export LD_LIBRARY_PATH=/opt/moonshot/lib64/:/usr/lib64/freeradius/:$LD_LIBRARY_PATH
fi
After, either restart your shell session, or:
source /etc/profile.d/moonshot.sh
This is necessary as moonshot currently stores its modified libraries separately to the main system ones to avoid conflicts. This should not be necessary in the future.
2. Update SELinux to be permissive
Moonshot has a couple of outstanding issues regarding proper labeling of SELinux contexts, causing it to fail when SELinux is enforcing. This should be resolved soon - change the setting in /etc/sysconfig/selinux, or in /etc/rc.local:
echo 0 > /selinux/enforce
3. Configure HTTP and HTTPS proxy for Yum
For us to be able to configure CentOS, Yum needs to be able to access the Internet via a proxy.
4. Install EPEL
Moonshot needs EPEL for a few extra libraries (as pulling them from a semi-supported repository is preferable to repackaging).
The simplest way to install EPEL is:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
5. Configure Yum's Moonshot repository
The RPMs and SRPMs for Moonshot are currently hosted at http://repository.project-moonshot.org/rpms/centos6/ - this may change (and in fact, is quite likely to change) in the future. The packages are signed (currently with exception of libevent2).
Example /etc/yum.repos.d/moonshot.repo
[Moonshot]
name=Moonshot
baseurl=http://repository.project-moonshot.org/rpms/centos6/
failovermethod=priority
gpgcheck=0
gpgkey=http://repository.project-moonshot.org/rpms/centos6/moonshot.key
After setting up the repository definition, we'll set up a composite ORPS/IdP in a later step.
6. Install Moonshot and FreeRADIUS
To install the Moonshot GSS implementation and FreeRADIUS, use the following:
yum install moonshot-gss-eap freeradius
Note: Depending on the database support you wish to enable in FreeRADIUS, you must issue the following commands to first list and then install the correct module from the main repository:
yum list freeradius*
yum install freeradius-<database>
7. Install Kerberos
If Kerberos is not installed, install it, its client and its test utilities:
yum install krb5-devel krb5-server krb5-libs krb5-workstation
Note: After testing your configuration, you can remove the Kerberos test utilities with the following command
yum erase krb5-devel
8. Configure Kerberos
Configure Kerberos, you ask? But I'm not using Kerberos! True, but the Kerberos library is kind of self-centered at the moment and doesn't believe anyone would ever want to not use Kerberos. So, it requires that servers be able to set up Kerberos even if they never use it.
Modify the contents of /etc/krb5.conf:
[libdefaults]
default_realm = YOUR_DOMAIN_ALL_CAPS
Then run ktutil. At the ktutil: prompt, enter:
addent -password -p host/hostname.your_domain@YOUR_DOMAIN_ALL_CAPS -k 1 -e aes256-cts
Enter a password of your choice, remember it. Then enter
wkt /etc/krb5.keytab
quit
Then, optionally, chmod a+r /etc/krb5.keytab.
Note: Making /etc/krb5.keytab read-only would be a very bad thing to do if you actually were using Kerberos. It may still be a bad thing to do if you have services enabled that can potentially use Kerberos.
9. Configure libradsec
This tells the Moonshot SP where to find a RADIUS server for authentication. Moonshot will ultimately use RADSEC for communicating with the RADIUS server - in which case you would use transport="TLS" and service="2083" in /etc/radsec.conf
Ultimately, the final values depend on the deployment - probably the address, port and secret used by your ORPS:
cat > $prefix/etc/radsec.conf << EOF
realm gss-eap {
type = "UDP"
timeout = 5
retries = 3
server {
hostname = "$hostname"
service = "1812"
secret = "$secret"
}
}
EOF
$secret is the secret you share with the radius server, i.e. the "secret" entry in FreeRADIUS configuration "client" clause.
$hostname is the host of the RADIUS server, in this case, we will use the local server just configured, so 'localhost' or ' 127.0.0.1' will do
10. Configure RADIUS
Once FreeRADIUS is installed, we need to fix up the dictionary by creating a soft link in /usr/local/raddb called dictionary to /etc/raddb/dictionary. If necessary, create the appropriate directories.
FreeRADIUS 2.1.x has not been updated with the new attributes for Moonshot yet. Edit /usr/share/freeradius/dictionary.ukerna and replace the four attributes beginning with GSS with the below:
ATTRIBUTE GSS-Acceptor-Service-Name 164 string
ATTRIBUTE GSS-Acceptor-Host-Name 165 string
ATTRIBUTE GSS-Acceptor-Service-Specific 166 string
ATTRIBUTE GSS-Acceptor-Realm-Name 167 string
A source of identity needs to be enabled for RADIUS - either the roaming network in the case of an ORPS (such as eduroam), or AD/LDAP/etc for an IdP.
For now, we'll just use a flat file. Open /etc/raddb/users and locate the following fragment:
# This is a complete entry for "steve". Note that there is no Fall-Through
# entry so that no DEFAULT entry will be used, and the user will NOT
# get any attributes in addition to the ones listed here.
#
# steve Cleartext-Password := "testing"
# Service-Type = Framed-User,
# Framed-Protocol = PPP,
:
:
Uncomment the line beginning steve.
Chargeable-User-Identity is the value used to decide what user account to log in the user as on the network/resource/service.
This value would normally be set by your local RADIUS proxy (ORPS) - so in a real deployment, rather than statically logging the user in as moonshot you may decide to use something like steve-camford.ac.uk.
If anonymity is required, you could use a Perl or Python script to generate something like user-789-camford.ac.uk.
The exact value does not matter - only that the mappings are consistent, so that the user gets access to the same local account each time. To allow creation of accounts on demand you could use LDAP - when the ORPS sees a successful authentication, it could trigger a script that creates the desired account in an LDAP domain. It is not guaranteed that Chargeable-User-Identity will be used permanently - in the future a specific RADIUS attribute may be created instead. Note: In the case of an ORPS you need to unfilter this attribute in /etc/raddb/attrs to prevent this attribute from being stripped on roaming requests.
To activate CUI insertion, edit /etc/raddb/sites-enabled/default, and find the post-auth section, and add the following:
update reply {
SAML-AAA-Assertion = '<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" IssueInstant="2011-03-19T08:30:00Z" ID="foo" Version="2.0">'
SAML-AAA-Assertion += '<saml:Issuer>urn:mace:incommon:osu.edu</saml:Issuer><saml:AttributeStatement>'
SAML-AAA-Assertion += '<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"><saml:AttributeValue>steve@local</saml:AttributeValue></saml:Attribute>'
SAML-AAA-Assertion += '<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"><saml:AttributeValue>moonshot</saml:AttributeValue></saml:Attribute>'
SAML-AAA-Assertion += '</saml:AttributeStatement></saml:Assertion>'
}
Finally, set the EAP type in use by moonshot (EAP-TTLS) by editing /etc/raddb/eap.conf
default_eap_type = md5
becomes:
default_eap_type = ttls
Other EAP types should be supported (PEAP and MD5 tested).
Before starting FreeRADIUS, check that it is set to run on server restart with the following command:
chkconfig |grep radiusd
If necessary, use chkconfig radiusd on to enable automatic start for FreeRADIUS.
FreeRADIUS now has a very minimal IdP/ORPS configuration, and can be started with:
service radiusd restart
If you encounter any issues, you can run radius in debug mode to see what is going on internally.
service radiusd stop
radiusd -X
When in debug mode, FreeRADIUS acts as an interactive program, so it should be run on a separate console, or under GNU Screen.
11. Configure Shibboleth
Moonshot uses libshib to parse RADIUS and SAML attributes - SAML assertions can be embedded inside RADIUS responses by the IdP, allowing an ORPS to exercise a very fine-grained authorization policy. In the demo we just use a very simple example - mapping the Chargeable-User-Identity to a local user account, but in a real deployment you could map a SAML attribute to the user account just as easily.
Edit /etc/shibboleth/shibboleth2.xml and insert the following lines if they don't exist:
<Extensions>
<Library path="plugins.so" fatal="true" />
</Extensions>
Edit /etc/shibboleth/attribute-map.xml and change the line below from entitlement to local-login-user. In the standard Moonshot distribution, SSH will look for local-login-user to determine who to log in as:
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" id="entitlement"/>
This attribute mapping will be managed by the XML assertion in the FreeRADIUS reply for a successful authentication.
12. Configure GSS
Create a soft link in /usr/lib/gss called mech_eap.so to /usr/lib64/gss/mech_eap.so
Next, a file is created in the home directory at ~/.gss_eap_id - this is the file that Moonshot looks in for credentials. The format is very simple - username followed by a password on separate lines. For now, set it to:
steve
testing
In a deployment with a GUI, this file is replaced by the Moonshot Identity Selector. It is conceivable in the future that the Identity Selector GUI will be supplemented with a curses-like UI, or other mechanism allowing console usage.
/etc/gss/mech tells moonshot what encryption options are valid for use with GSS. Create such a file and copy this contents into it
#
# Sample mechanism glue configuration for EAP GSS mechanism.
#
# Any encryption type supported by Kerberos can be defined as the
# last element of the OID arc.
#
eap-aes128 1.3.6.1.5.5.15.1.1.17 mech_eap.so
eap-aes256 1.3.6.1.5.5.15.1.1.18 mech_eap.so
13. Test the functionality
As mentioned earlier, we will be using the Kerberos test tools to make sure that things are working. To start the gss-server, run:
gss-server host@localhost &
There are two ways to start gss-client - the first specifies an encryption method to use by its OID 1.3.6.1.5.5.15.1.1.18 (as seen in /etc/gss/mech):
gss-client -mech "{1.3.6.1.5.5.15.1.1.18 }" 127.0.0.1 host@localhost bar
The second uses Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO)
This chooses the "best" mutually-agreeable encryption method for between client and server. To invoke the client using SPNEGO, use:
gss-client -spnego 127.0.0.1 host@localhost bar
Sample Output
Attribute local-login-user Authenticated Complete
moonshot
6d6f6f6e73686f74
UID: 501
Accepted connection: "steve"
Sending init_sec_context token (size=150)...continue needed...
context flag: GSS_C_MUTUAL_FLAG
context flag: GSS_C_REPLAY_FLAG
context flag: GSS_C_SEQUENCE_FLAG
context flag: GSS_C_CONF_FLAG
context flag: GSS_C_INTEG_FLAG
"steve" to "host/$hostname", lifetime -1, flags 13e, locally initiated, open
Name type of source name is { 1 2 840 113554 1 2 1 1 }.
Mechanism { 1 3 6 1 5 5 2 } supports 4 names
0: { 1 2 840 113554 1 2 1 1 }
1: { 1 2 840 113554 1 2 1 2 }
2: { 1 2 840 113554 1 2 1 3 }
3: { 1 2 840 113554 1 2 1 4 }
Received message: "testing"
Signature verified.
NOOP token
Running gss-client produces a massive amount of output.
The important part is at the end - you should see output similar to what is on the previous slide.
If you do not see the line:
Attribute local-login-user Authenticated Complete
Then attribute mapping is not functioning properly, and you need to check your Shibboleth configuration.
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom