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.
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.
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 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!
Pseudonymity
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