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