Moonshot comprises several parts: the client, the service, the RP proxy, the identity provider and the trust router.

The client, comprising the GSSAPI mechanism and the identity manager (on supported platforms), enables the use of Moonshot through existing GSSAPI support. The client must be installed on all parties in a Moonshot deployment: on the client device (a laptop, for example), the service, the RP proxy, the identity provider and the trust router (where applicable), so that all parties can understand the protocol. The API to access the client is the standard GSSAPI.

The service may be any service that supports multi-trip GSSAPI (many modern applications do, but some need help). The service generally does not need modification unless it is to add GSSAPI support where it previously did not exist. A prime example of this may be NFSv4, which may not support GSSAPI unless support has been built in during package creation.

The RP proxy is the gateway service between a GSSAPI-based service and the wider Moonshot network that uses the RadSec protocol for authentication purposes through the FreeRADIUS v3 package. The RP proxy also interacts with the trust router service to identify itself before querying the latter for realm information. Performance will depend almost entirely on the SQLite and FreeRADIUS software, which is designed to be very responsive in high-throughput environments.

The identity provider is a virtually standard FreeRADIUS v3 installation, with a change that allows it to interact with the trust router service and RP proxies that connect to it. As such, the identity provider will support all identity stores that FreeRADIUS will support (e.g. LDAP directories, relational databases, flat files), as well as SASL authentication based on username and password provided by the user. Performance here will depend on the speed and indexing of the identity stores as well as the hardware provided to the identity provider. As with the RP proxy, FreeRADIUS is designed to be responsive in a high-throughput environment. Any additional queries, such as to an attribute authority, will also have an impact on overall performance.

The trust router service provides the support for the trust between entities; it maintains the list of identity realms and their assigned hosts, the list of service realms and the constraints that bind them, as well as the communities of interest, which may be used in a similar fashion to virtual organisations (VOs). The trust router software has been designed to be available for use in a clustered/multi-instance environment. It is recommended that a proxy is placed in front of the service to handle request management better across multiple instances.

The main AARC requirements supported are: