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.
...
In order to build this fork of Moonshot you should perform the following steps:
- Follow steps 1 and 2 of https://wiki.moonshot.ja.net/display/Moonshot/Build+Moonshot+from+Source
- cd moonshot/
- mv moonshot moonshot.original
- git clone https://bitbucket.org/umujanet/moonshot-aaa-saml.git
- mv moonshot-aaa-saml moonshot
- cd ..
- 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:
| Code Block |
|---|
@testrealm.org @myaa.es |
The Moonshot library will take care of sending Attribute Queries to these AAs and combining their responses.
...
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:
| Code Block |
|---|
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.