Kolab Groupware is a collaboration suite establishing the integration of various applications you know already; Most prominently, these include 389 Directory Server, Postfix, Cyrus IMAP and Roundcube. Together, these applications would comprise a simple mail system that, in terms of functionality, would fall short of “groupware” and “collaboration” functionality.

Side-note: Cyrus IMAP has added CalDAV, CardDAV and WebDAV capabilities, encroaching on the territory Kolab otherwise occupied, rather exclusively, for as far as the world of Free Software is concerned. As such, Cyrus IMAP provides more of the groupware functionality than I initially stated, but does not provide ActiveSync capabilities, a web-mail client interface, Resource Management, and many other facilities included with Kolab Groupware. Inversely, however, Kolab is going to need to show to be the most adaptable, and applaud and welcome and embrace these developments in Cyrus IMAP, rather than attempt to compete with it somehow.

This blog post is about Single Sign-On and second factor authentication, however, and where and how these fit in with Kolab.

First, we need to clarify the terminology, because SSO and 2-factor authentication both mean different things to different people.

Single Sign-On

Single Sign-On is the functionality in which a complete infrastructure of services provided allows you to authenticate precisely once, and only ever once, from which point on forward you are trusted to have identified yourself — contrary to where you can use the same credentials over and over against different services, but you have to fill out and submit your credentials again and again to create valid sessions.

The ability to use the same credentials everywhere is usually achieved by making individual applications use the same authentication and authorization database in very much the same way — usually LDAP in some form or the other, or a SQL database. In principle your credentials fly over the wire time and time again in exactly the same way they would otherwise, they just happen to be the same credentials every time.

That is not to say that in a Single Sign-On scenario, no credentials go over the wire. They just so happen to not be your username and password, but separate ones issued to you, and negotiated the level of trust for between multiple parties — you, the issuer and the service. The clearest, cleanest and best example of this is Kerberos.

Two-Factor Authentication

Two-factor authentication — or multi-factor authentication — involves the functionality to supplement what you know (your password) with something you have. This translates to a token of sorts, usually presented in a physical form or encasing (an application’s configuration on a smart phone), that you are required to have on you and is expected to never change ownership. This can be a YubiKey, a smartcard, a phone, and such.

Since these devices are eligible to contain a form of processing power, most common implementations of the second factor today are one-time passwords — supplemental tokens that are valid precisely one time, or for a limited window in time — without involving space it is understood this is sufficient.

In the realm of Kolab especially, your username is often widely known — after all, an email address is rather limited in functionality unless your mailbox is to remain empty. More broadly speaking, your username tends to be known regardless — Twitter handles, Google email addresses, etc.

Back to Kolab

As I’ve mentioned before, Kolab has multiple access points — IMAP, SMTP, LDAP, the various web applications such as Roundcube, ActiveSync, CalDAV, CardDAV and WebDAV. The difficulty in applying Single Sign-On and Two-Factor Authentication needs to be viewed in the context of some of these separate applications being required to authenticate to other applications as you. How, though, does a web-mail client interface authenticate as you when it needs access to IMAP, LDAP or SMTP?

Proxy Authorization?

The first option is to consider the fact that IMAP, LDAP and SMTP have a concept of “proxy authorization”, where a set of credentials other than your account’s is used to authenticate, and the connection is subsequently authorized as if it had been your account logging in to begin with. More specifically, IMAP and SMTP provide this functionality as part of their use of SASL, and LDAP provides these capabilities separately.

However, this means these credentials would need to be available to the client application. Using these credentials with additional privileges (proxy authorization) over the user’s credentials constitutes privilege escalation, hopefully followed by de-escalation, and is therefore generally considered bad practice, especially in the context of services exposed to the Internet.

Central Authentication Service?

Another option is the Central Authentication Service (CAS). With such a service, you typically authenticate via a web application, which submits your credentials to CAS for verification. The web application is then issued tokens representing the validity of your session. When the web application in question needs to authenticate to another service as you, it submits the temporary credentials associated with the specific session, and therefore allows the third party application to validate the tokens in question as being a part of an existing session (again via CAS), operating under conditions to be expected — i.e. Roundcube connecting to Cyrus IMAP. Contrary to popular belief, this isn’t necessarily limited to just web services doing so, and can perfectly well be applied to non-web service endpoints as well.

However, a full desktop client to IMAP, such as Kontact, would not necessarily understand the need to consult a web service for obtaining tokens then valid against IMAP or SMTP. IMAP nor SMTP (or, actually, SASL) itself does not provide an authentication mechanism through which a full desktop client can be told to facilitate such type of external authentication.

OTP for Two-Factor Authentication

Therein lies the problem with OTP as well. There is currently no mechanism in which IMAP or SMTP (again, actually SASL) can be told to authenticate against a website first. While it can be required to issue an OTP, no SASL server-side implementation I’m aware of allows either of these to occur through a centralized authentication service. Feel free to leave your recommendations in the comments.

Cyrus SASL does not currently support OAUTHBEARER nor XOAUTH2 mechanisms. Alternatives like gSASL do not do so either. No full desktop client software that I’m aware of supports it — feel free to leave your recommendations in the comments below. Kolab does not currently support it, in that it is not an OAuth or OAuth2 provider.

Several other mechanisms achieving a similar relaying of the authentication process to occur outside of the IMAP or SMTP connection — SAML20 and OPENID20 come to mind, both of which are implemented in GNU’s SASL. For what it’s worth, Kolab is not a SAML nor OpenID provider currently, either.

I could, if I wanted, break these down in to work units — enhancement tickets if you will. I have, in fact, opted to include an OAuth provider in my new PACK project for this reason among others. Either, though, is slightly beyond the scope of this post (albeit not this blog).

Identity Management

A third option is viable only for fully integrated Identity Management solutions, where FreeIPA comes to mind. With FreeIPA, we may consider the Kerberos ticket issued valid, optionally so only after a valid second factor has also been submitted to obtain the ticket. Relaying the authorization is a bit of a pain, but we’ve managed in a Proof-of-Concept implementation for which I did the work, and the patches against Roundcube and the Kolab-specific authentication plugins have been accepted. The deployment scenario under which this is considered a viable option however is rather limiting. You do not typically deploy a Kerberos environment on the Internet in the first place (while work is ongoing to make that a more reasonable approach), but then still, a single client operating system (on to which the user logs in and applications get launched) is also typically associated with a sole provider environment. Long story short, I associate this typically with a single environment within a single organization, rather than a hosted or even colocated Kolab Groupware deploment.

Conclusion

While not one particular conclusion set in stone, several options result in various combinations of units of work. We could protect access using OTP and subsequently allow only the web client to be used by those that feel all access must be protected with OTP.

We could use CAS to further reduce the number of points where copies of credentials need to be saved off as those points require access to other services as you, while protecting privilege escalation vector-based attack surfaces. We could use an OAuth2 provider to negotiate the authorizations for the various applications that Kolab includes.

Comments and ideas welcome, as I feel we’re (I am) breaking ground on new territory.

Post navigation

4 thoughts on “Kolab, SSO and Second Factors”

Yes, it is a matter of the client application and the service which way the service allows the client application to proof the identity of the user.

I am into 2-factor-authentication with the management system privacyIDEA. So what do you recommend for a 2FA system? I guess the only thing a 2FA-system can do is support all possible authentication protocols, be it old RADIUS or Kerberos or Web SSO like SAML, OpenID Connect? What about SASL?

There’s no one free and open solution I’m aware of, that exists today and is currently available for and implemented in all client software to all entry points — IMAP/SMTP, browser-based web client software, *DAV, ActiveSync, can work on discovery (i.e. Kerberos or OAUTH 1) rather than static configuration (sometimes in code, i.e. OAUTH 2), scales well beyond a first or second party, is available to all client platforms (Windows, Mac and Linux), does not use privilege escalation and does not put forth unreasonable requirements to its users (such as having to buy a particular piece of hardware).

However, not all those conditions or restrictions are applicable to all deployments equally — a single organization deploying an application or suite of applications can choose one particular mechanism and stick with it, even if that includes side-effects and sub-optimal conditions; road warriors (people on the move that connect from external to the organization’s network) use web-mail and web-mail only, or are given software configured so that it works, or told the way things work, or …

I have some ideas on solving the problem of SASL server- and client-software not being able to negotiate a second factor is required for the particular user account that attempts authentication, in such way that it does not require a client to supply the second factor to each and every authentication attempt (i.e. with every mail submitted or with every INBOX refresh), which I think does not involve unreasonable requirements for the user — but that is probably another blog post entirely, once I have a Proof-of-Concept implementation and thought through all the consequences.