Rick van Rein

wo 16 september 2020


Identity 16: Support Levels for Realm Crossover

The essential game of Realm Crossover is one of juggling realms as part of identities. This brings us a number of "support levels" that we could describe. This forms an interesting perspective on the growing path of the InternetWide Architecture.

This article explains the approach for support of BYOID to this article series on identity.

We design solutions for hosting providers. This means that what we design would scale to large customer bases. That does not mean that it cannot be run on individual services, however. Inasfar as the diagrams below seem complicated, this is mostly due to our recognition of more concepts than usual; the actual software that needs to run is modest enough. It just has a few more hinges, with great client freedom as a major benefit.

We discuss SASL at length, and briefly turn to the simpler models for Kerberos and GSS-API near the end. We also touch upon pseudonymity near the end of this article.

Level 0: Plain SASL Authentication

Basic authentication assumes that a client is local to the realm that also operates a service. The client does have a unique client userid, but not a client realm because the realm is provided by the service. The result is an identity userid@service.realm where userid is authenticated by SASL under the service realm.

SASL in Local Authentication

As an example of this, you might think of a typical email server, which requires login with an account on that server. This model works well for email, because our mail server makes global connections on our behalf, and at the other end email pickup is once again a local process. At most, the model sacrifices some flexibility for shared mailing lists.

For web services, the same model is problematic. Having accounts on each and every web service is a common problem these days, and because most bog down to the most stupid model that they know, namely password authentication, security is downright bad. No surprise then that we are designing a way out.

Level ½: Plugin Services or "Static" Realm Crossover

Plugin Services assume a hosting provider, specialised on a service that domain owners can plugin through a references in DNS. The business model for the hosting provider is massive hosting with specialisation on the service. You certainly could do worse but you also might do better with a more integrated approach to identity. This is what we propose here. We still derive userid@service.realm identities.

SASL in Hosted Plugin Services

This approach uses a simple backend API and protocol that we called diasasl. This is a TCP/IP connection on the local network, over which SASL requests can be passed to a central authentication backend. The protocol and API are really simple and integrate with blocking processes or threads as well as modern event-looping service architectures. We have made it as easy as we can imagine to integrate diasasl as the umbilical cord to your locally trusted identity node.

The local identity node is setup to relay requests to the serviced realm if one is requested that is not locally defined. This is made possible with Diameter, which shines in just this kind of realm-crossing authentication connections; it mutually authenticates over TLS and pools connections, so it is quite efficient in connecting to other realms and securely exchange SASL mechanisms. We defined an embedding of SASL into Diameter for this purpose.

This setup allows a client to run their own identity provider as a SASL-over-Diameter service, announce it in DNS with the proper protections with DNSSEC/DANE/TLS. Any party willing to host a service for the realm would use diasasl from a service to reach their central identity node, which then connects to the hosting client's own realm for login.

The realm of a Plugin Service is, strictly speaking, a realm configured for the service. This is why we call it "static" realm crossover. It is possible that the realm is derived from a protocol element, such as a host name or a path. This gives some form of flexibility, but the client still ends up under the service-configured realm.

A concern with this setup is that it is not safe to use with any login method. The service provider sees the SASL traffic flowing by, and not all methods are secure in that form. Some are, but one has to be cautious. The next level offers a better alternative.

Level 1: Realm Crossover with SXOVER

Public Services are even more open than Plugin Services, in that anyone may use them. In this case, the solution should even work without server configuration. Furthermore, it is not usually reasonable to trust a public service to see the authentication details passing through, especially when no service contract can be negotiated. Being the most flexible, this mechanism can also be used for the previous levels.

The pivotal point for allowing any client to use a public service is to facilitate Bring Your Own IDentity by granting clients to provide their own domain, with their own identity provider using a straightforward standard for realm-crossing authentication. The public service would use diasasl to connect to their local identity node, which knows just enough about SASL to detect the desired client realm, connect to it over Diameter, and relay SASL traffic.

SASL in Public Services

SASL can be flexibly extended with new mechanisms; we designed one named SXOVER, specifically for use with Realm Crossover. This mechanism starts off by stating a client realm, under which a client userid can be obtained. SXOVER is like an end-to-end encrypted tunnel between the client and the identity provider in their realm. The additional use of channel binding information allows the client to ensure that they are authenticating to a particular public server and not any backend other than the identity provider.

The client realm is authenticated over Diameter, which means that it can be trusted by the public service; routing is however completely dynamic and no prior knowledge of the client realm is required for client login. Based on the trusted connection to the identity provider for the client realm is trusted, its claims of user identity underneath can be trusted too. We can therefore derive userid@client.realm identities; clients BYOID!


The best point to switch a client identity to an alias is during Realm Crossover, and SASL can provide this through authorisation identities; the first step is authentication under a primary identity and an optional second step is to switch to another identity, as specified by the client. Validation of this switch is required, for which we developed the identity inheritance idea.

Next to the use of an identity without active email account or simply a fresh one to thwart tracking across sites, a good use of identity switching is to access a service under a group account, for instance purchase when accessing a sales service without necessarily acting as an individual.

Mixing Support Levels

There is no issue with the mixed support of these levels. The inquiry for supported SASL mechanisms is always answered by the service realm, in all scenarios. Only when the SXOVER is offered and chosen by the client will level 1 commence. This will be offered when dynamic realm crossover is available for that service. Our diasasl protocol has a standard realm, namely the empty string, to allow quick provision of SXOVER and nothing else.

A setup for level 1 can be resolved locally if the sending and receiving ends of Diameter are on the same node. The connection will be made locally and more efficiently.

Realms that are available locally can be redirected to a normal SASL library with underlying account databases. If this is the only option, such as at level 0, then the link can be directly made from the application service. Note that nothing stops this direct connection to be made in a diasasl implementation, in which case maximum flexibility can be offered.

Kerberos and GSS-API

The examples above detail how Realm Crossover for SASL works, but we also have a mechanism in development for Kerberos. This is perhaps a more advanced model; both in terms of the knowledge needed and the quality and functionality.

Kerberos and GSS-API authentication carry a realm as part of the client identity, and so it can easily express all three levels. The question is how it maps to infrastructure.

At level 0, the client identities are part of a local ACL and this is the common usage pattern. Level ½ compares to "classical" Realm Crossover for Kerberos, based on manually configured crossover keys; in Microsoft terms, this is the formation of a forest. Level 1 is our full-blown setup with the KXOVER protocol that we designed for Impromptu Realm Crossover; again, the full dynamicity that allows any client to approach any (public) service.

Go Top