1. Overview

An Identity Provider (IdP) is an authoritative source of identity information for users affiliated with the organisation running the IdP. Relying Parties (RPs) will have a trust relationship of some kind with the IdP that means they trust it to authenticate and authorise users.

The Client interacts directly with the IdP through a secure tunnel that passes through the Service and its RP Proxy. The user proves who they are to the IdP through this tunnel via a credential exchange of some kind (e.g., passing a username and password across).

Once the user has successfully authenticated to the IdP, the IdP in turn responds to the Service via the Service's RP proxy; it may provide information solely to acknowledge that a user authenticated correctly, or it may provide further information in the form of attributes such as name or membership information.

2. Requirements

2.1. RADIUS server with Moonshot capability

The Moonshot IdP is a RADIUS server with Moonshot extensions. Currently, FreeRADIUS is the only RADIUS software that has these Moonshot extensions.

2.2. Moonshot Mechanism

The IdP must have the Moonshot mechanism installed and configured within the operating system. This will take the form of the GSS-EAP mechanism configured in the GSS stack.

This mechanism enables software on that machine to make use of Moonshot as a potential GSS-API/SSPI mechanism for authentication.

2.3. Configured to talk to a Trust Infrastructure

The IdP will need to be configured with an upstream connection to a trust infrastructure of some kind. Exactly what this will be will depend on the trust infrastructure in use, but will likely include information on how to connect to that trust infrastructure (e.g., details for a Trust Router, or details for a RADIUS proxy), along with relevant keying material.

3. How Moonshot is used on the IdP.

In general terms, the Moonshot IdP receives an incoming authentication request from an RP proxy, establishes a connection to the Client through the RP, receives credentials from the Client, verifies these credentials, and sends a yes or no to the RP, plus optional attribute information about the user in RADIUS headers or a SAML assertion.

More specifically:

1. The IdP receives an incoming request to open a RadSec connection from a Moonshot RP Proxy. Assuming it already has keying material for that RP Proxy (see the trust section, for now assume that this happens magically), it opens this connection.
2. A TLS tunnel is now established between the Client and the IdP, via the RP Proxy. This means there is a path for EAP messages to be sent between Client and IdP (client to App over GSS-EAP, App to RP Proxy over their RadSec connection, RP Proxy to IdP over their RadSec connection)]
3. Inside of this tunnel an EAP message in encapsulated which the IdP receives, along with the name the RP Proxy is claiming for itself. Additionally, a SAML Authentication Request could be present.
4. The IdP begins an EAP conversation with the Client. The IdP and Client choose which EAP method to use. TTLS is chosen, and a secure inner tunnel between Client and IdP is established, that none of the intermediate points (RP Proxy, App server) can see.
5. The IdP receives a set of credentials down the inner tunnel, along with channel binding information (the name of the RP that the client is trying to contact).
6. These credentials are authenticated (e.g., checked against an LDAP directory). Also, the IdP checks that the Client provided RP and the RP claimed RP name are the same.
7. Assuming the credentials are correct, EAP messages are exchanged, magic happens, and both IdP and Client now have an MSK and EMSK.  
8. The IdP decides whether user should be allowed to use the service. If so, it sends the RP Proxy an Access-Accept with EAP success encapsulated, possibly a SAML assertion relating to the user in question, and the EAP MSK.