Versions Compared

Version Old Version 12 New Version 13
Changes made by

Stefan Paetow

Stefan Paetow

Saved on

Key

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

...

Numberedheadings
start-numbering-with1

Introduction

It often is the case that a user may have multiple identities he/she would like to associate with their local account. For example, a scientist may wish to use their institutional identity (as issued by their home institution), as well as perhaps a Google or Facebook account, where allowed.

It is also the case that not all associations are trusted equally. In some cases, the institutional identity may have a higher level of assurance than a social platform like Google or Facebook, and the organisation may wish to restrict logging into more sensitive systems to identities with higher levels of assurance. For example, the scientist is allowed to use their Google or Facebook account to sign into reference libraries, user accounts, project and grant submission systems, but may only use their institutional identity to log into data libraries containing sensitive research data.

Based on these two requirements, i.e. multiple identities and different levels of assurance, a database table with three columns is sufficient. 

The examples on this page use MySQL as the database dialect and RHEL or one of its derivatives as the operating system. If using a different database technology or OS, convert the commands or FreeRADIUS filesystem paths as relevant.

Configure the Database

The first thing that is needed is a database to store these mappings. In your favourite database server software, create a table with three columns:

targeted_idlocal_uidauth_type
varchar(256)varchar(32)smallint
Example - Creating the mapping table in MySQL

In MySQL, you can achieve this with the following command:

bash

The first column is the primary key and the values stored here will be the incoming targeted identifier. The incoming value will generally be qualified, i.e. it will be a value with the incoming realm appended to it (i.e. value@REALM). The width is limited to the maximum length of the SAML eduPersonTargetedID attribute. Alternatively, you may wish to use the maximum length of any RADIUS attribute (253 octets).

The second column is the local account name. The width is limited to the maximum length of useradd(8) on Unix. On Windows, underlying usernames are limited to 20 characters for compatibility purposes (see Microsoft TechNet: Active Directory Maximum Limits - Scalability for more information on this).

The final column is for information (and possibly integration) purposes and contains an identifier that identifies the service used. Suggested values are zero, indicating a local-to-local mapping, one indicating a Moonshot mapping, and any other value thereafter for clearly defined values as per your organisation's choice. This field could also indicate the level of assurance.

 

Configure the RP Proxy

The second thing needed is to configure your Moonshot RP Proxy (or Moonshot IdP if you are using that as both an IdP and an RP Proxy) to make use of the database of mappings.

Enable the FreeRADIUS SQL module

To access the database from your Moonshot RP proxy (FreeRADIUS), you must configure FreeRADIUS to enable database support. FreeRADIUS by default supports SQLite, MySQL/MariaDB, PostgreSQL, and any database that supports Unix ODBC connections. However, depending on your database dialect, you may have to install the FreeRADIUS module for it to enable this support.

Example - adding support for MySQL to FreeRADIUS

To add support for MySQL in FreeRADIUS on RHEL, issue the following command:

bash

 

After installation, configure the SQL module:

  1. Edit /etc/raddb/mods-available/sql

  2. In the sql section, adjust the driver value to your database dialect as per the comments above it:

    true
  3. Depending on your database dialect, you may wish to adjust some of the options that are specific for your database dialect. 

  4. Adjust the dialect line to match your database dialect as per the comments above it:

    true

  5. Remove the comments from the server, port, login and password lines and adjust them to suit:

    true

    You must ensure that the login user and password are created in the database before you start the FreeRADIUS server. See your database documentation on how to create users in your database, or use the supplied FreeRADIUS setup scripts for your database dialect to create a default database.

  6. Adjust the radius_db line to suit your database dialect. Take note of the additional options documented that may be applicable to your database dialect.
  7. If you do not use RADIUS accounting, check or reply items, and/or don't store your users in a database, comment out any tables that are not applicable to you.

  8. Save the file and create a soft link to enable the SQL module:

    bash

Using the Moonshot-Host-TargetedId attribute in a database lookup

A typical Moonshot deployment uses three pseudonymous targeted identifiers as issued by a Moonshot IdP - the Moonshot-Host-TargetedId, Moonshot-Realm-TargetedId, and Moonshot-TR-COI-TargetedId. These are carried as ordinary RADIUS attributes - see for furhter further information on these identifiers and how an IdP can be is configured to issue them.

To use these identifiers as the incoming attribute to be used as the remote identifier for the user, do the following.:

 Create a mapping policy configuration

  1. In FreeRADIUS' /etc/raddb/policy.d directory, create a file named "moonshot".

  2. In this file place the following content:

    truecpp

    The logic of the code above is simple but very constrained:

    1. You receive a reply from an ID Provider (including your own) in the Moonshot system.
    2. If it is a trust router request, don't do anything.
    3. If that reply contains the Moonshot-Host-TargetedId, execute a SQL query in your database for the Moonshot-Host-TargetedId.
      1. If there is a local account mapping for the Moonshot-Host-TargetedId, set the Tmp-String-1 attribute to the local account for it.
      2. If there is no local account mapping for Moonshot-Host-TargetedId, set the Tmp-String-1 attribute to the Moonshot-Host-TargetedId
    4. If the reply does not contain the Moonshot-Host-TargetedId, do nothing and Tmp-String-1 will not be set to anything.
    5. Next, delete any SAML assertion contained in the SAML-AAA-Assertion attributes in the reply.
    6. Finally, create a new SAML Assertion, but this time use the value of Tmp-String-1, if it exists. If it does not, use 'moonshot'.
    Enable

Enabling the mapping policy

To use the policy, it has to be enabled by using it.

  1. In /etc/freeradius/sites-enabled/abfab-tr-idp, find the post-auth section. At the top, insert onto its own line the following:

    true

    You can adjust where you want to call the policy that inserts the Moonshot policy, as long as it is called in the post-auth section of abfab-tr-idp.

    If you use non-TLS connections for Moonshot, you may wish to repeat Step 2 in /etc/freeradius/sites-enabled/default.

  2. Restart FreeRADIUS.

Using an incoming SAML assertion in a database lookup

This section is still being written. Check back soon...