Multi-AA support for Moonshot

Owned by Alejandro Perez
Last updated: Nov 01, 2016
3 min read

Introduction

Moonshot defines a process by which the IdP that authenticates an end user generates/obtains a SAML assertion containing end user's attributes and sends it to the RP along with the success authentication notification. This assertion is processed by the Moonshot layer on the RP, and the attributes within it are provided to the RP (e.g. SSH, Apache, etc.) as GSS-API attributes. See RFC 7056 for details on the format of these attributes.

However, in some situations, a specific RP may wish to query a different AA (Attribute Authority) to obtain further attributes about the end user. Supporting this use case requires some changes on the Moonshot source code. The fork of Moonshot available from https://bitbucket.org/umujanet/moonshot-aaa-saml.git) allows exactly that, following two different approaches. Nothing precludes using both approaches simultaneously, although they cover different use cases.

  1. The Moonshot layer of the RP specifies a list of AAs from where it would like to obtain attributes. Right after the authentication of an end user, these AAs will be queried to get all attributes they have about the end user. All the attributes (the ones from the authenticating IdP and the ones from each AA on that list) are provided together in a single SAML assertion to the RP.

    This approach is configured at a Moonshot library level. That is, RPs (e.g. SSH, Apache...) will not be aware of this multi-AA environment. They will receive the attributes as in any other regular Moonshot authentication.

  2. The RP directly queries a AA to get a specific end user attribute, at any moment after the end user authentication. The attribute is provided in a single SAML Assertion to the RP.

    This approach requires modifying the RP application (e.g. SSH) to pro-actively request a specific attribute at some moment (you can imagine a web application that at some moment asks for a specific attribute in order to grant the user access to a restricted resource).

Shared identifiers across AAs

For allowing these use cases to work there is need for a shared identifier across all the AAs and IdPs of the federation. In the case of our implementation, we have chosen the EduPersonPrincipalName (EPPN), with OID 1.3.6.1.4.1.5923.1.1.1.6. This attribute MUST be present on the SAML assertion sent by the authenticating IdP, and will be used as Subject of the Attribute Queries sent to the AAs. If the attribute is not present, the multi-AA support will not be executed.

Installation

In order to build this fork of Moonshot you should perform the following steps:

  1. Follow steps 1 and 2 of https://wiki.moonshot.ja.net/display/Moonshot/Build+Moonshot+from+Source
  2. cd moonshot/
  3. mv moonshot moonshot.original
  4. git clone https://bitbucket.org/umujanet/moonshot-aaa-saml.git
  5. mv moonshot-aaa-saml moonshot
  6. cd ..
  7. Follow step 3 of https://wiki.moonshot.ja.net/display/Moonshot/Build+Moonshot+from+Source

Usage

Approach 1

Create a file called /etc/abfab_multiaa.txt. In that file, introduce an IdP/AA realm per line, in the form @realm. For example:

@testrealm.org
@myaa.es

The Moonshot library will take care of sending Attribute Queries to these AAs and combining their responses.

Approach 2

On the source code of the specific RP application you are using (e.g. SSH), make an explicit call to the gss_get_name_attribute. If attribute name follows RFC 7056 conventions, the query will be sent to the authenticating IdP. However, if the AA's realm is added as an additional suffix, the query will be sent to that particular AA. For instance, using the following attribute name:

 

urn:ietf:params:gss:federated-saml-attribute urn:oasis:names:tc:SAML:2.0:attrname-format:uri urn:oid:1.3.6.1.4.1.5923.1.1.1.7 myaa.es

will send a SAML Attribute Query to the myaa.es RADIUS IdP, asking for the eduPersonEntitlement of the authenticated end user.