The Trust Router trusts.cfg file is in JSON format, and for processing and automation reasons, the format generated by the Moonshot portal lists each delimiter (square and curly brackets) on a separate lines.
This page is designed to make the file easier to read and understand.
The top level
The top level of the trusts.cfg file defines three lists of entities, which are the communities in this trust infrastructure, the Identity Provider (IdP) realms and the Relying Party (RP) clients. The latter list defines groups of RPs that share sets of APC credentials.
{ "communities": [ {community1}, {community2}, ... ], "idp_realms": [ {idp_realm1}, {idp_realm2}, ... ], "rp_clients": [ {rp_client_group1}, {rp_client_group2}, ... ] }
Communities
The communities
list contains the communities in this trust infrastructure. There is always a minimum of one community in a trust infrastructure, the Authentication Policy Community (APC). It is the over-arching community that includes all RPs and IdPs.
{ "apcs": [ "apc" | empty ], "community_id": "name of the community", "idp_realms": [ "idp_realm1", "idp_realm2", ... ], "rp_realms": [ "rp_realm1", "rp_realm2", ... ], "type": "apc" | "coi" }
- The community ID,
community_id
, must be in FQDN format, i.e. apc.moonshot.ja.net, or csc.communities.moonshot.ja.net - The APC community has an empty
apcs
field and itstype
field is "apc" - Communities of interest (COI) will set the
apcs
field to "apc" and theirtype
field to "coi" - The community's
idp_realms
list contains the identity provider realm names that are part of the community.- In the case of a COI, each entry must also be part of the APC community's
idp_realms
list. - Each entry in this list must have an entry in the top-level
idp_realms
list for anaaa_server
with a matchingrealm_id
value.
- In the case of a COI, each entry must also be part of the APC community's
- The community's
rp_realms
list contains the relying party (RP) realms that are part of the community.- In the case of a COI, each entry must also be part of the APC community's
rp_realms
list. - Each entry must have a corresponding
filter_lines
entry in one of therp_clients
groups in the top-levelrp_clients
list
- In the case of a COI, each entry must also be part of the APC community's
Identity Provider realms
The identity provider realms list idp_realms
contains a list of entries that define the identity realms available in this trust infrastructure. This realm list will include the APC as well, as the APC is not just a community, but also the identity provider for all the relying parties in the trust infrastructure. Each identity provider realm uses the below format:
{ "aaa_servers": [ "rp_realm1" ], "apcs": [ "apc" ], "realm_id": "idp_realm1", "shared_config": "yes" | "no" }
The
aaa_servers
entry must contain anrp_realm
entry that belongs to the organisation that owns (or manages) the realm inrealm_id
.
Thisrp_realm
entry must have a correspondingfilter_lines
entry in one of therp_clients
groups in the top-levelrp_clients
list.The
rp_realm
entries on the upstream trust router for anyidp_realms
entries connected to downstream trust routers must point to the trust router they are connected to.Example: IDP1 is connected to Trust Router B, which is downstream from Trust Router A. On Trust Router A, IDP1's
rp_realm
entry must be set to Trust Router B'srp_realm
entry, while on Trust Router B, therp_realm
for IDP1 points to its realrp_realm
entry.- The
realm_id
must be listed in theidp_realms
list of at least the APC. You may add it to other communities as well to make that realm available as an ID Provider in those communities. The
shared_config
option is currently not used and should be said to "no".
Relying Party client groups
The relying party clients list rp_clients
contains a list of groups that define the relying party clients available in this trust infrastructure. Relying party (RP) clients authenticated with the same credential in gss_name
are grouped together, with each RP client identified by a filter_lines
entry. Each RP client group uses the below format:
{ "filter": { "filter_lines": [ {filter_line1}, {filter_line2}, ... ], "type": "rp_permitted" }, "gss_names": [ "gss_name1", "gss_name2", ... ] }
- The
gss_names
entries are the accepted APC credentials for this group ofrp_clients
. The
filter_lines
entries in thefilter
entity arerp_realm
entries that will be authenticated with the samegss_name
entries.The
rp_realm
entries on the upstream trust router for anyrp_realm
entries connected to downstream trust routers must be grouped together in anrp_clients
group that authenticates with thegss_names
entry of the downstream trust router.Example: IDP1 and RP2 are connected to Trust Router B, which is downstream from Trust Router A. On Trust Router A, IDP1 and RP2's
filter_lines
entries are authenticated using Trust Router B'sgss_names
entry, while on Trust Router B, each host has its ownrp_clients
group with its owngss_names
entry (where appropriate).
Filter lines (RP client filter definitions)
The filter_lines
list in an rp_clients
group contains RP client filters for RP realms that are identified by this rp_clients
group. Each filter_line
entry follows the below format:
{ "action": "accept", "domain_constraints": [ "domain_constraint_1", ... ], "filter_specs": [ { "field": "rp_realm", "match": "value1_of_rp_realm" }, { "field": "rp_realm", "match": "value2_of_rp_realm" }, ... ], "realm_constraints": [ "value1_of_rp_realm", "value2_of_rp_realm", ... ] }
- The
domain_constraints
list should at least contain one of therealm_constraints
entries, but an empty list is acceptable. - Each entry in the
realm_constraints
list must have a corresponding entry in thefilter_specs
list. - The bare minimum of such an entry should contain the FQDN name of the RP in the
domain_constraints
andrealm_constraints
, and a correspondingfilter_specs
entry.
An example file:
Here is an example trusts.cfg file. A full description of the various sections follows
The communities
list
This list starts at line 1 and ends at line 32.
It contains two communities, apc.moonshot.ja.net
and pilot.communities.moonshot.ja.net
.
The APC community starts at line 3 and ends at line 18. It contains three idp_realms
(line 7-11) and three rp_realms
(line 12-16) entries.
The pilot COI contains one idp_realms
(line 24-26) and one rp_realms
(line 27-29) entry. Each of these entries is present in the APC's corresponding lists.
The idp_realms
list
This list starts at line 33 and ends at line 64.
It contains three idp_realms entries, apc.moonshot.ja.net
(line 34-43), ms-idp.dev.ja.net
(line 44-53) and ms-idp.ja.net
(line 54-63).
Each entry (excepting apc.moonshot.ja.net
) contains a aaa_servers
entry that matches one of the rp_realms
in lines 12-19, and each entry contains a realm_id
entry that matches one of the idp_realms
entries in lines 7-11.
The rp_clients
list
This list starts at line 65 and ends at line 176.
It contains two RP client groups, one for e018e5bd-c37b-45d1-b48c-93c92a15aa31@apc.moonshot.ja.net
(line 69-117) and one for edc3fa84-4bb7-4df4-b90a-11f807000511@apc.moonshot.ja.net
(line 118-147).
The first group contains two rp_clients
, ms-ssh-sp.dev.ja.net
(line 72-90) and ms-idp.dev.ja.net
(line 91-110), the other group contains one rp_client
(line 121-140).
Each of these rp_clients
entries corresponds to one of the rp_realms
defined in the APC community.
Each of these rp_clients
entries has a filter_specs
list entry for each realm_constraints
list entry, and the domain_constraints
list contains at least one of the realm_constraints
.