3.3.3 Proxied Federation

Before · SP 800-63C

After · SP 800-63C-4

Proxied Federation

Before · SP 800-63C

After · SP 800-63C-4

In some architectures, the IdP and RP do not communicate directly with each other. A federation proxy acts as an intermediary between the IdP and RP for all communication in the federation protocol. The proxy functions as an RP on the upstream side and an IdP on the downstream side, as shown in Fig. 1 . When communicating through a proxy, the upstream IdP and downstream RP communicate with the proxy using a standard federation protocol, and the subscriber takes part in two separate federation transactions. As a consequence, all normative requirements that apply to IdPs and RPs SHALL apply to proxies in their respective roles on each side. Additionally, a proxy can act as an upstream IdP to a downstream proxy in a chaining scenario.

The role of the proxy is limited to the federation protocol. It is not involved in the establishment or facilitation of a trust agreement between the upstream IdP and downstream RP. The same party can operate a federation authority and a proxy to facilitate federation transactions, but the proxy function is separate from the federation authority’s role in managing the trust agreement. Just like other members of a federation system, the proxy can be involved in separate trust agreements with each of the upstream and downstream components, or a single trust agreement can apply to all parties, such as in a multilateral agreement. Proxy

IdP / Wallet RP

Upstream Downstream IdP / Wallet RP

Fig. 1. Federation proxy

The downstream RP receives and validates the assertion generated by the proxy, as it would an assertion from any other IdP. This assertion is based on the assertion that the proxy receives from the upstream IdP. The contents of the assertion from the upstream IdP can be handled in several ways, depending on the method used by the proxy:

• The proxy can create a new assertion with no information from the assertion from the upstream IdP carried in it. This pattern is useful for blinding the downstream RP so that the RP does not know which upstream IdP the subscriber originally came from.

• The proxy can copy attributes from the assertion from the upstream IdP into the assertion from the proxy. This pattern is useful for carrying identity attributes in the assertion to the downstream RP.

• The proxy can include the entire assertion from the upstream IdP in the assertion from the proxy. This pattern allows the RP to independently validate the assertion from the upstream IdP and the assertion from the proxy.

The federated identifier (see Sec. 3.4 ) of an assertion from a proxy SHALL indicate the proxy as the issuer of the assertion.

A proxied federation model can provide several benefits. Federation proxies can simplify technical integration between the RP and IdP by providing a common interface for integration, as well as providing translation between federation protocols, formats, and schemas. Additionally, to the extent that a proxy effectively blinds the RP and IdP from each other, it can provide some business confidentiality for organizations that want to guard their subscriber lists from each other. Proxies can also mitigate some of the privacy risks described in Sec. 3.10 , though other risks arise from their use since an additional party is now involved in handling subscriber information. For example, if an attacker is able to compromise the proxy, the attacker need not target the IdP or RP directly in order to gain access to subscriber attributes or activity since all of that information flows through the proxy. Additionally, the proxy can perform additional profiling (i.e., aggregating information on which identity the subscriber uses at which RPs) of the subscriber beyond what the IdP and RP can do, since the proxy brokers the federation transactions between the parties and binds the subscriber account to either side of the connection.

See Sec. 7.5 for further information on blinding techniques, their uses, and their limitations.

The FAL of the connection between the proxy and the downstream RP is considered to be the lowest FAL along the entire path, and the proxy SHALL accurately represent this to the downstream RP. For example, if the connection between the upstream IdP and the proxy is FAL1 and the connection between the proxy and the downstream RP otherwise meets the requirements of FAL2, the connection between the proxy and the downstream RP is still considered FAL1. Likewise, if the connection between the upstream IdP and the proxy is FAL2 and the connection between the proxy and the downstream RP is only FAL1, the overall connection through the proxy is considered FAL1.

A subscriber-controlled wallet could potentially function as a proxy. To do so, wallet software would need to act as an RP to an external IdP, just as any other proxy, and then provide those attributes to the downstream RP.

In some systems, the proxy is referred to as a broker.