Components of the Trust Router

Owned by Alex Perez Mendez
Last updated: May 05, 2020
2 min read

A detailed description of the components that take part into a Trust Router infrastructure

The components of a Trust Router infrastructure can be grouped in two leves: high and detailed.

The high level components are the following:

  • IDP (Identity Provider). A RADIUS server that handles authentication for one or more Identity Realms (e.g. jisc.ac.uk or google.com). IDPs are also always RPP.
  • RPP (Relying Party Proxy). A RADIUS server wanting to establish a dynamic trust relationship with an IDP, typically able to convey EAP packets coming from a user belonging to that IDP's identity realm trying to access to a connected application or RP (Relying Party). 
  • TR (Trust Router server). A server trusted by both, the RPP and the IDP, that acts as an mediator for the establishment of a direct trust relationship between both entities.
  • APC (Authentication Policy Community). A RADIUS server handling the so called APC authentication realm, with credentials for all the involved components (IDP, RPP, and TR). There is a pre-configured trust-relationship between the APC and the TR.

All the high level components run a combination of the following lower level components:

  • TIDC (Temporary IDentity Client): Application/library that is used to perform TID queries to the TR to resolve information about a specified authentication realm. The most relevant pieces of information received from the TR are:
    1. The hostname/IP address of the IDP handling the specified authentication realm.
    2. The IDP's DH public key for generating the shared key between the RPP and the IDP.
  • TIDS (Temporary IDentity Server): Application listening for TID queries coming from the TR. It receives RPP's DH key exchange and generates the counterpart. It also stores the generated key into /var/lib/trust_router/keys associated to the requesting realm.
  • TR (Trust Router). Application listening for TID queries coming from RPPs and forwarding them to the respective IDPs based on the configured federation information. It also mutually authenticates with the invoved parties using Moonshot, being the APC the IDP for federation entities.
  • FR (FreeRadius).
    • On an RPP, it uses the TIDC library to dynamically create the security association with the IDPs of the users trying to authenticate the Applications connected to this RPP.
    • On an IDP/APC, it consumes the keys stored in /var/lib/trust_router/keys to recognise trusted RPPs.