Rick van Rein

vr 30 december 2016


Identity 7: Welcoming Guests

While we are tightening our infrastructure, we may also consider letting guests into our setup. As you might expect, we intend to do this in the tightest possible manner.

Welcoming Unexpected Guests

A proper identity architecture should have a way of dealing with unexpected guests. There is always the possibility of granting anonymous access to anyone, but could there also be a mechanism that grants rights to returning users, and that will continue to welcome them with the same user identity as they presented before? That would really make it a Bring Your Own IDentity platform!

And indeed, this is possible. When we consider the inheritance of identities it is clear that some rewriting of addresses needs to be done. Much of this is internal to the realm or domain name, but there are some extra paths over which foreign identities are welcome too:

Inheritance of Identities

Clearly, there is a use for translation of foreign identities into realm-bound welcoming identities that they might take up. There may in fact be multiple such identities for any given foreign identity, so in general we need to concern ourselves with a list of local renames.

Given this, what could be more natural than allowing a special role named guest, and assigning role occupants some names such as guest+c669d08ba0d920f09b16343cbd3daadabb89b3e7fa789529c5768d5e87f946f5 (based on a SHA-256 hash) when we care about the security of the returning visit, or perhaps guest+c3427811db296605 (based on a prefix of a hash) if our primary concern is privacy of the guest, or even just guest+jAwMDAwMjAg (based on a 64-bit fast but insecure hash) if we believe that even that is not a true concern? Sizes matter, but variation is thinkable. We may also think about the form being a hex number, base64 encoding or even just show the original identity in the plain.

There is no real reason for not supporting such guest identities for foreign identities and, in fact, for local identities as well. The one thing we need to do is set aside a user identity to serve as the guest role, and decide on the occupant production rules. We shall not be granting anyone any access until they actually pass through an ACL that allows them.

Note that we are not saying that we intend to setup any service for such guests, but rather to welcome them as authenticated but pseudonymous visitors in parts of our infrastructure that have been setup with a sufficiently permissive ACL.

The ACL is where things may get interesting; this is where we can easily specify user names like guest+sha256 to indicate that the first format is welcomed. Although it is theoretically possible to generate identities on the fly, we would rather be lazy and do it only when it is called for. So a bit of special handling in the authorisation phase might be all that is called for.

The use of hashes means that we do not get to log the identities of our visitors; we only get to distinguish them as being the same as before. And when presented with a complaint from some foreign user, we can help them, because then we can forward-compute the hash and lookup log entries.

Image credit: fletcherjcm — the work has been cropped to a horizontal bar.

Go Top