Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The trust router's 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 collections of entities, which are the communities in this trust infrastructure, the Identity Provider (IdP) realms and the Relying Party (RP) clients. The latter collection generally defines the organisations that are part of the infrastructure, because organisations will generally use one set of credentials for all their relying parties.

The top level
{
  "communities": [ {community1}, {community2}, ... ],
  "idp_realms": [ {idp_realm1}, {idp_realm2}, ... ],
  "rp_clients": [ {rp_client_group1}, {rp_client_group2}, ... ]
}

 

Communities

The communities collection 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 Relying Parties and Identity Providers. It is worth noting here that all realms in the idp_realms collection are also part of the rp_realms collection, as all identity providers are relying parties, but not all relying parties will be identity providers.

community
{
  "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 emptyapcs field, and its type field is "apc"
  • Communities of interest (COI) will set the apcs field to "apc" and their type field to "coi"
  • The community's idp_realms collection 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 collection.
    • Each entry in this collection must have an entry in the top-level idp_realms collection for an aaa_server with a matching realm_id value
  • The community's rp_realms collection 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 collection.
    • Each entry must have a corresponding filter_lines entry in one of the rp_clients groups in the top-level rp_clients collection

 

Identity Provider realms

The identity provider realms collection idp_realms contains a collection of entries that define the identity realms available in this trust infrastructure. This realm collection will include the APC as well since the APC is not just a collection, but also the identity provider for all the relying parties in the trust infrastructure. Each identity provider realm uses the below format:

idp_realm
{
  "aaa_servers": [ "rp_realm1" ],
  "apcs": [ "apc" ],
  "realm_id": "idp_realm1",
  "shared_config": "yes" | "no"
}
  • The aaa_servers entry must contain one rp_realm entry that belongs to the organisation that owns (or manages) the realm in realm_id.

    This rp_realm entry must have a corresponding filter_lines entry in one of the rp_clients groups in the top-level rp_clients collection

  • The realm_id must be listed in the idp_realms list of at least the APC. You may add it to other communities as well.

 

Relying Party client groups

The relying party clients collection rp_clients contains a collection 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_line entry. Each RP client group uses the below format:

rp_client
{
  "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 of rp_clients. 
  • The filter_lines entries will be rp_realm entries that will be authenticated with the same gss_name entries.

 

Filter lines (RP client filter definitions)

The filter_lines collection 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:

filter_lines
{
  "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 collection should at least contain one of the realm_constraints entries, but an empty collection is acceptable.
  • Each entry in the realm_constraints collection must have a corresponding entry in the filter_specs collection.

 

 

 

  • No labels