IdentityHub 2: Middleware from Heaven

// under architecture idhub hosting

In a series of 3 independent articles, we're introducing the current design of the IdentityHub. We intend to start this work in March 2017.

The middleware of the IdentityHub is designed for flexible use; it supports our powerful use of identities and implements our goals of privacy and security through self-control over online presence. This is where concepts such as Bring Your Own IDentity and its technical realisation through Realm Crossover come alive.

Please note: If you followed our postings with some degree of accuracy, you may have noticed how we gradually refine the architecture and are pretty much delivering to our promise. The most obvious question that bothers us is our financial continuity, to be quite honest. So, if you find parts of this design useful and others promising, maybe you should contact us to help us settle the financial side.

.. Find the Middleware in the middle column

Authentication in the TLS Pool

During our first project phase SecureHub we separated TLS handling out into a TLS Pool that is now approaching its 1.0 release. We also designed and implemented the TLS-KDH mechanism that enables proper use of Kerberos within TLS connections -- an astounding amiss in today's security landscape, certainly because Kerberos is in common use, for instance as part of Active Directory. Many other protocols use SASL for authentication, which is not (yet) done in the TLS Pool, but that often also leads to Kerberos authenication.

In all these cases, we aim to implement and support realm crossover, meaning that users from remote realms can employ their local Kerberos credentials to authenticate remotely. This is new in the sense that the crossover can be made on the fly, when it is in demand. We also do this for X.509 and OpenPGP, using the LDAP Global Directory, but there it is much more expensive: Kerberos realm crossover is done once between two realms, and the crossover is established for all users at once, for days to come; X.509 and OpenPGP on the other hand, need to validate the same things over and over again, using expensive public-key cryptographic operations. Our research into TLS-KDH found that our approach is about ten thousand times faster on average!

Note that we use the TLS Pool strictly for authentication and treat authorisation separately below.

Authorisation

The mechanisms for authorisation build the IdentityHub's flexible user identity logic on the foundations of an identity that was authenticated by the TLS Pool or SASL.

This phase answers questions such as

Can user_A behave like user_B?
Can user_B access resource_R, and if so, what rights does it have?
Can (remote) user_B communicate with user_C?

Within the IdentityHub, we have one entity of control (the hosting provider), so we do not have to put in the privacy effort that we need towards plugin services. Our main concern here is to be efficient, and support large-scale operations. To that end, the authorisation module is responsible of caching and low-cost access mechanisms in the service of other components.

Control over the IdentityHub

Users of the IdentityHub will regularly want to do things to their service; they may want to add domain names (or phone numbers), user accounts, aliases and pseudonyms, they may want to add or remove members from a group or role, and so on.

The control of such requirements is managed over remote control interfaces. There are currently two that we are contemplating:

remctl because it facilitates simple user interfaces to be operated from relatively poor user interfaces such as those found on mobile phones and tablets;
a RESTful API because it integrates well with most other software and client platforms, including laptops, desktops and automated processes run from server systems.

Our current expectation is that both will be used.

One task of this control interface for the IdentityHub is to list the currently available options to authorised users; for instance, to show the current list members to the list administrator, so that one may be removed or perhaps upgraded to list administrative status.

The interaction with the component comes down to sending a command to schedule configuration actions; some of these will involve generating new key material and configuring new access relations.

Managing the IdentityHub

Sitting behind the control interface, there is the logic of the IdentityHub, which is silently groveling on whatever tasks it needs to. This involves not only the generation of new key material and cleanup of old, but it also deals with automatic rollover of keys. All this is possible inasfar as (private) keys are hosted by the IdentityHub.

On top of this, many signaling paths may be initiated by the IdentityHub as soon as it is possible. Relatively complex facilities such as DNS data with DANE and DNSSEC also find a place in this component.

You may view the module as a guard for the health of the entire cryptographic logic of the IdentityHub.

The complete series

Go Top

Rick van Rein