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.
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:
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.
.jpg?uselang=en-gb){kind=link}