Skip to main content

Federated User Identity Registration

Overview​

Federated user identity is a complex topic, but can be simply described as how do we identify users and how do we verify their source.

info

In this context, "verify their source" refers to the procedure of validating that a service purporting to act on behalf of a specific user has the proper authorization to do so.

Standard DNS identity​

A standard approach to federated identity is to use email addresses (or similar), where there is a user part and a domain part. Verification of the source leverages the domain part and requires a service to present a certificate where the domain is in the Subject Alternative Name field, and is signed by a trusted Certificate Authority. This is standard domain certificate validation procedure used by the World Wide Web, XMPP, SIP, Email, etc.

Federated User Identity Registration- Standard DNS Names Figure 1 - User registration using standard DNS names

An approach using standard DNS names and user@domain identity is shown in Figure 1:

  1. A user logs on to their local MindLink service, authenticating with their certificate.
  2. The local MindLink service establishes federation to a remote MindLink service by performing mutual TLS authentication.
  3. The local MindLink service registers the local user using their *user@domain *identity, i.e., user@local.
  4. The remote MindLink service validates the federated connection can represent the registered user identity by checking the domain part of the identity against the source server Subject Alternative Names certificate field.
  5. The remote MindLink service requests the attributes from their attribute server for the local user.
  6. The remote Attribute Server requests the local user attributes from the local attribute server (assuming federated attribute servers).
  7. The local Attribute Server returns the attributes for the local user.

On-behalf-of​

This procedure is all well and good if the service can present such a certificate. However, what if a service is allowed to represent a domain, but may not be able to present a valid certificate for the target domain.

Email does have a mechanism to support services of this kind - SPF records. An SPF record is a DNS record registered in the source domain that identifies other DNS names that are allowed to represent its users. When receiving a request on-behalf-of a user in a given domain, the source can be validated against the SPF records of that domain.

An augmented diagram using standard DNS with on-behalf-of validation is shown in Figure 2:

  1. A user logs on to their local MindLink service, authenticating with their certificate.
  2. The local MindLink service establishes federation to a remote MindLink service by performing mutual TLS authentication.
  3. The local MindLink service registers the local user using their user@other identity, i.e., user@other.
  4. The remote MindLink service sees that the user domain does not match the source server Subject Alternative Names certificate field and so queries the user domain for TXT records of the form v=mlspf1 include:local.
  5. The remote MindLink service validates that the DNS query finds a record that includes the local service as an authorized party.
  6. The remote MindLink service requests the attributes from their attribute server for the local user.
  7. The remote Attribute Server requests the local user attributes from the local attribute server (assuming federated attribute servers).
  8. The local Attribute Server returns the attributes for the local user.

Federated User Identity Registration- Standard DNS Names and on-behalf-of-flow

Figure 2 - User registration using standard DNS names and on-behalf-of flow

Complications​

We want to leverage the standard approach, however, identity in our customer environments is based on Distinguished Names (DNs). This rules out the usage of standard DNS and certificate validation procedure.

To complicate things further, SPF records work because you query the source DNS records to retrieve alternatives, but there is no way to reach a DN for a query (there is no DN equivalent for DNS names). You cannot leverage standard DNS-based identity either, as there is no guarantee that a user identity of the form user@domain will have any relation to their DN!

Second-hand identity​

It is possible to validate a user directly using certificate based authentication, and from their certificate source their DN. However, this first-hand identity is not possible over a federated connection, where you only have the other server’s certificate available to you. Instead, the source server will provide second-hand user identity that you cannot directly validate and must rely on the trust established at the server level.

In order to validate user DNs we intend to leverage local configuration to validate external identity sources. The local administrator defines the relationship between DN suffixes and federated domains, for example:

chat.remote:
    DN=remote,DN=com
    DN=other,DN=org

Due to the complications we have described, we must rely on a local source of information in order to trust that a remote domain is allowed to represent a given DN suffix. To avoid extraneous dependencies, local configuration is leveraged, but an Attribute Server could be used if the federated connection provided a non-person entity (NPE) identity that could be queried.

Federated User Identity Registration- Registering with Distinguished Name

Figure 3 - Registering users with their Distinguished Name

Figure 3 shows how MindLink is able to register users using a DN:

  1. A user logs on to their local MindLink service, authenticating with their certificate.
  2. The local MindLink service establishes federation to a remote MindLink service by performing mutual TLS authentication.
  3. The local MindLink service registers the local user using their DN identity, i.e., CN=user,O=company,DC=local,DC=tld.
  4. The remote MindLink service uses the DN trust configuration and searches for a registered suffix that matches the user DN for the federated connection identity, local.
  5. The remote MindLink service requests the attributes from their attribute server for the local user.
  6. The remote Attribute Server requests the local user attributes from the local attribute server (assuming federated attribute servers).
  7. The local Attribute Server returns the attributes for the local user.