Last updated: 
2 months 1 week ago
Group Manager
Project Moonshot is a Janet-led initiative, in partnership with the GÉANT project and others, to develop a single unifying technology for extending the benefits of federated identity to a broad range of non-Web services, including Cloud infrastructures, High Performance Computing & Grid infrastructures and other commonly deployed services including mail, file store, remote access and instant messaging. The goal of the technology is to enable the management of access to a broad range of services and applications, using a single technology and infrastructure. This is expected to significantly improve the delivery of these services by providing users with a common single sign-on, for both internal and external services. Service providers will be able to more easily offer their services to users from other organisations using a single common authentication mechanism. This will enhance the user’s experience, and reduce costs for those organisations supporting users, and delivering services to them. This group is for community of Moonshot users, whether you're new to the technology, you're currently evaluating and getting to grips with it, or you've deployed it. For the list of guidance available about Moonshot within this group, see the Start Here wiki page. Jisc Assent, the production service underpinned by the Moonshot technology, went live on 25th March 2015. For information on, or to join the Jisc Assent service, please visit

Implementation and Technology Questions

This page is to capture implementation and technology questions that would be useful to share with the Moonshot Community. For more general FAQs please see

Q. How are real Linux usernames and Identity Selector usernames connected?
A. The Linux server will potentially get an NAI through RADIUS and an attribute through SAML. On the server you could then map directly from the NAI/SAML provided value to a local account, or map using a locally stored mapping table. This is a policy decision and depends on the application.

Q. Who assigns the local name - is it the RP or the IdP?
A. Again, this is a policy decision so it could be either.

Q. Does the Identity Selector only support username/password?
A. Moonshot supports any authentication method that is supported by any EAP method. However, the current version of the Identity Selector only supports username/password. (But there is no reason why it cannot be developed further to support other authentication methods.)

Q. How does the Identity Selector authenticate the Home AAA server?
A. On Windows, you can select a certificate store in the msetup GUI. If you do that, then any certificate chaining back to a trust anchor in that certificate store will be accepted. On Unix, there are a number of methods you can use. The recommended method is to include the SHA 256 hash of the certificate that will be used in EAP-TTLS in the XML file loaded into the Moonshot UI to provision an identity.
Unfortunately, because of a bug reported at the certificate is not actually checked. Fixing that bug is a high priority and this answer will be updated as soon as it is resolved.
Long-term we'll be including the same UI in the Windows product that we have for the Unix product and will be using reasonably consistent semantics for validation.

Q. So we're assuming that the eduroam credentials are the Home (SAML) IdP credential (same identity backend)?
A. Correct.

Q. Is the client server secure path created via eap-ttls? If so, how do you validate the certificate?
A. The Trust Anchor validates the certificate.

Q. Is the Identity Selector acting like a supplicant, which could use TLS certificates to authenticate the Home server? A. Yes, the Identity Selector is the same as a supplicant in eduroam.

Q. There are some references to Shibboleth IdP - I guess any SAML IdP would do?
A. We have a freeRADIUS module for pySAML - Roland Hedberg's SAML implementation. You can use that directly, or you can use it to talk to any existing SAML implementation via attribute query or ECP.