Bring Your Own IDentity

For clients, being able to control an online identity is not just a cool matter of adding their domain name at the end. It also means that they control how long the identity exists, if it is an alias, if it can be a group account with members that they control. (We made identity and access control libraries to support all that, along with identities that are only usable until a timeout, from a certain remote domain, under a particular communication topic, and so on.) For servers, being able to authenticate users from any domain is an answer to many questions that otherwise stagnate: * Why does every HTTP server want us to create an account under its domain, instead of letting us use our own? * Why do we constantly need to confirm our email address by clicking links? * Why not authenticate SMTP senders and subject others to the most stringent spam filtering? * Why not publish a mailing list archive in IMAP, available only to subscribers and searchable with their own tooling? * Why not use AMQP as an automation-friendly document push protocol with authenticated senders for form submission, bill processing, blog publications, document archiving, ... * Why not share your MQTT dataflow with external parties, so they don't need to keep a web page open to be notified about, say, a newly posted document? * Why not share your PGP keys and contact information in your own LDAP directory but with access control to decide who may see what? All these questions stagnate on problems like *You would need to have accounts for all users in the World*. So that is what we solved in this project. This project expands the usefulness of many protocols by changing the way their implementations handle authentication; instead of local accounts, they follow a backlink to the client's domain. We designed and built the extensions needed for the backend, and made a few first implementations. We are hoping to show the usefulness of adopting these ideas in your own tooling. We present a number of generic mechanisms for Realm Crossover: 1. SASL tokens can be relayed to a Diameter server under the domain.name; 2. Kerberos supports Realm Crossover, and a keying handshake can do this on-demand; 3. X.509 certificates and PGP keys can be assured with DANE-akin structures for clients or by a lookup in an LDAP server for domain.name. For each, some form of domain-owned identity provider is run to assert identity when an external service needs it. The level of security is a matter of the user and their domain.name; an external service should not have to force down the security level of the client's domain. These three Realm Crossover mechanisms cover the majority of application protocols, the notable exceptions being the oldest ones, like Telnet, FTP and HTTP. Specifically for HTTP, we have defined an authentication mechanism that adds SASL; this means that new security mechanisms can be defined in SASL, where it benefits many protocols; it also means that authentication shifts from the HTTP application to the server, where the coding environment is better suited for such responsibilities. We end with a demo, showcasing a useful authentication flow: * Client desktop, with FireFox and a HTTP-SASL plugin * Server domain, running Apache with HTTP-SASL module under an independent domain * Server identity client, using Diameter to relay SASL to the Client Domain * Client Domain, running an identity provider with SASL over Diameter