An introduction to Wt::Auth

  • Posted by koen
  • Monday, November 14, 2011 @ 21:23

A large patch landed in our git repository last week. This was the result of the merge of a development branch that has kept us busy over the last months.

In a series of posts, we will give an overview of the new modules that were added to Wt, starting here with Wt::Auth, an authentication module.

In future posts, I will discuss other novel modules such as Wt::Http (Http client), Wt::Json (JSON library), and Wt::Mail (SMTP client), which were developed under the impulse of the authentication module.

Note
 If you’re a JWt user, you should be aware that for several of these new modules we are still fleshing out a suitable Java API. The reason is that we first want to find out which Java libraries can be leveraged for some of the functionality that is not easily ported to JWt, and this may impact some of the API choices.
Functional overview

The authentication module implements the logic and widgets involved in getting users registered on your application, and letting them sign in. Note that this module is entirely optional, and simply implemented on top of Wt.

The module implements authentication. Its main purpose is to securely authenticate a user to sign in to your application. From your application, you will interact with the authentication module using a Wt::Auth::Login object, which you typically hold in your application object. It indicates the user currently signed in (if any), and propagates authentication events.

How you use this information for authorization or to customize the user experience is out of the scope of the module. Because of Wt’s built-in security features, with strong (and actually, improved — but that should be the topic of another post) session hijacking mitigation, this is as straight forward as one can conceive it.

Currently, the module provides the following features, which can be separately enabled, configured or customized:

  • Password authentication, using best practices including salted hashing with strong cryptographic hash functions (such as bcrypt) and password strength checking.

  • Remember-me functionality, again using best practices, by associating authentication tokens stored in cookies to a user.

  • Verified email addresses using the typical confirmation email process.

  • Lost password functionality that uses the verified email address to prompt a user to enter a new password.

  • Authentication using 3rd party Identity Providers, currently using OAuth 2, with support for multiple identities per user. We’ve added an implementation using Google, but others will be added, and in the future we may expect standardization using OpenIDConnect.

  • Registration logic, which includes also the logic needed to merge new (federated login) identities into existing user profiles. For example, if a user previously registered using a user name and password, he may later also authenticate using for example his Google Account and this new identity is added to his existing account.

The logic for these features is implemented separately from the user-interface components, which can be customized or completely replaced with your own widgets.

Next to traditional password-based authentication, we’ve been careful to have a design that accommodates 3rd party identity providers (federated login) such as Google, Twitter, Facebook, etc… and other authentication mechanisms in general (authenticating reverse proxies, client SSL certificates, LDAP, token devices …).

Federated login is a compelling proposition, but has currently not had widespread success, because of usability issues and other problems, including privacy concerns. There are a number of exciting developments however which promise to resolve this:

  • OpenIDConnect is the much plagued OpenID protocol redone, but this time on top of OAuth2.0, and aims to be the "open and distributed" alternative to Facebook Connect. In particular it solves the confusion of using URLs as identity, and instead has moved on to email addresses. There is an auto-discovery protocol that queries your email provider, and this should eliminate most privacy concerns (because you do trust your email provider, don’t you ?).

  • AccountChooser aims to provide a consistent and universal method for users to sign in to websites. Together with the use of the email address-as-identity this might just work.

  • Implementing a usable federated login system is complex, and increasingly so. Not only is the logic daunting (account linking is one example), it also requires a good mix of Ajax-y user-interface components, server-side logic and state with a protocol that involves receiving and sending HTTP requests, and integration into a traditional password-based authentication module. Well, we are solving that ;-)

Note
a plan coming together
OAuth2.0, OpenIDConnect, and AccountChooser are currently draft specifications. We plan to expand our support as these drafts turn into endorsed specifications. In particular, it would be a plan coming together when we add an AccountChooserWidget that complements the current Wt::Auth::AuthWidget and Wt::Auth::RegistrationWidget classes and which allows users to authenticate with any email provider using the OpenIDConnect discovery protocol.

Obviously, the authentication logic needs to talk to a storage system, and it is designed to hook into a storage system using an abstract interface. A default implementation that leverages Wt::Dbo, Wt’s ORM, is provided.

Module organization

The following picture illustrates the main classes of the library.

Wt::Auth components

It uses a classical separation between Model classes and View classes (which are the widgets).

There are three types of model classes:

  • Service classes are designed to be shared across all sessions (they do not have any state besides configuration). They contain logic which does not require transient state in a session.

  • Session bound model classes are usually kept in a session for the entire lifetime of a session (but don’t need to be).

  • Transient model classes play an active role in the user-interface, and are instantiated in the context of certain view components. They implement logic which involves state while the user is progressing through the login and registration process.

Example

The example below is a small example of an application that uses the authentication module. It is about 200 lines of C++ (which we’ll discuss below), and has the following features:

  • Password-based authentication and registration

  • OAuth-2 login and registration, for Google Accounts

  • Password attempt throttling

  • Email verification and a lost password procedure

  • Remember-me tokens

  • And by virtue of Wt itself, falls back to plain HTML behavior if the browser does not support Ajax, strong security, spam resilience, etc…

This example should help you to understand how to add authentication support to a new or existing Wt project.

This example is not available online, but we’ve updated the authentication system of the hangman example instead, to do authentication in pretty much the same way. You may want to play around with it (for example first registering using username/password and then using your Google account — for the same username).

1) Setting up a user database

We will be using the default implementation for an authentication database using Wt::Dbo, with the default persistence classes for authentication. This database implementation is found in Wt::Auth::Dbo::UserDatabase, and it uses Wt::Auth::Dbo::AuthInfo as the persistence class for authentication information, which itself references two other persistence classes:

  • A user’s "identities" are stored in a separate table. An identity uniquely identifies a user. Traditionally, a user would have only a single identity which is his login name (which could be his email address). But a user may accumulate more identities, corresponding to accounts with 3rd party identity providers. By allowing multiple identities, the user may identify using a choice of methods.

  • Authentication tokens are stored in a separate table. An authentication token usually corresponds to a "remember-me" cookie, and a user may have multiple "remember-me" cookies when using different computers.

In addition, we define a User type to which we can add the application data for a particular user (this could be address information, birth date, preferences, user role, etc…), and which we want to link up with the authentication system.

The definition and persistence mapping for (a currently empty) User type is as given below:

User.h
#include <Wt/Dbo>
#include <Wt/WGlobal>

namespace dbo = Wt::Dbo;

class User;
typedef Wt::Auth::Dbo::AuthInfo<User> AuthInfo;

class User {
public:
  template<class Action>
  void persist(Action& a)
  {
  }
};

We declare a typedef for AuthInfo, which links the authentication information persistence class to our custom User information persistence class.

Next, we define a session class, which encapsulates the connection to the database to store authentication information, and which also tracks the user currently logged in, in a web session. We choose to use the Wt::Dbo::Session class as a base class (which could just as well be an embedded member).

Later on, we’ll see how each web session will instantiate its own persistence/authentication Session object.

Session.h
#include <Wt/Dbo/Session>
#include <Wt/Dbo/ptr>
#include <Wt/Dbo/backend/Sqlite3>

#include "User.h"

namespace dbo = Wt::Dbo;

typedef Wt::Auth::Dbo::UserDatabase<AuthInfo> UserDatabase;

class Session : public dbo::Session
{
public:
  Session(const std::string& sqliteDb);

  Wt::Auth::AbstractUserDatabase& users();
  Wt::Auth::Login& login() { return login_; }

  ...

private:
  dbo::backend::Sqlite3 connection_;
  UserDatabase *users_;
  Wt::Auth::Login login_;

  ...
};

Notice the typedef for UserDatabase, which states that we will be using the Wt::Auth::Dbo::UserDatabase implementation using AuthInfo, for which we declared a typedef earlier on. You are of course free to provide another implementation for Wt::Auth::AbstractUserDatabase which is not based on Wt::Dbo.

We also embed a Wt::Auth::Login member here, which is a small model class that holds the current login information. The login/logout widgets will manipulate this login object, while the rest of our application will listen to login changes from this object to adapt to the user currently logged in.

The Session constructor sets up the database session.

Session.C (constructor)
#include "Session.h"
#include "User.h"

#include "Wt/Auth/Dbo/AuthInfo"
#include "Wt/Auth/Dbo/UserDatabase"

using namespace Wt;

Session::Session(const std::string& sqliteDb)
  : connection_(sqliteDb)
{
  setConnection(connection_);

  mapClass<User>("user");
  mapClass<AuthInfo>("auth_info");
  mapClass<AuthInfo::AuthIdentityType>("auth_identity");
  mapClass<AuthInfo::AuthTokenType>("auth_token");

  try {
    createTables();
    std::cerr << "Created database." << std::endl;
  } catch (std::exception& e) {
    std::cerr << e.what() << std::endl;
    std::cerr << "Using existing database";
  }

  users_ = new UserDatabase(*this);
}

The example uses a SQLite3 database (a cuddly database convenient for development), and we map four persistence classes to tables.

We then create the data schema if needed, which will automatically issue the following SQL:

create table "user" (
  "id" integer primary key autoincrement,
  "version" integer not null
)

create table "auth_info" (
  "id" integer primary key autoincrement,
  "version" integer not null,
  "user_id" bigint,
  "password_hash" varchar(100) not null,
  "password_method" varchar(20) not null,
  "password_salt" varchar(20) not null,
  "status" integer not null,
  "failed_login_attempts" integer not null,
  "last_login_attempt" text,
  "email" varchar(256) not null,
  "unverified_email" varchar(256) not null,
  "email_token" varchar(64) not null,
  "email_token_expires" text,
  "email_token_role" integer not null,
  constraint "fk_auth_info_user" foreign key
   ("user_id") references "user" ("id")
)

create table "auth_token" (
  "id" integer primary key autoincrement,
  "version" integer not null,
  "auth_info_id" bigint,
  "value" varchar(64) not null,
  "expires" text,
  constraint "fk_auth_token_auth_info" foreign key
   ("auth_info_id") references "auth_info" ("id")
)

create table "auth_identity" (
  "id" integer primary key autoincrement,
  "version" integer not null,
  "auth_info_id" bigint,
  "provider" varchar(64) not null,
  "identity" varchar(512) not null,
  constraint "fk_auth_identity_auth_info" foreign key
   ("auth_info_id") references "auth_info" ("id")
)

Notice the auth_info, auth_token and auth_identity tables that define the storage for our authentication system.

2) Configuring authentication

The service classes (Wt::Auth::AuthService, Wt::Auth::PasswordService, and Wt::Auth::OAuthService), can be shared between sessions and contain the configuration and logic which does not require transient session state.

A good location to add these service classes are inside a specialized Wt::WServer instance, of which you usually also have only one in a Wt process. You could also create a singleton for them. To keep the example simple, we will declare them simply as global variables (but within file scope): myAuthService, myPasswordService, and myOAuth.

Session.C (authentication services)
#include "Wt/Auth/AuthService"
#include "Wt/Auth/HashFunction"
#include "Wt/Auth/PasswordService"
#include "Wt/Auth/PasswordVerifier"
#include "Wt/Auth/GoogleService"

using namespace Wt;

namespace {
  Auth::AuthService myAuthService;
  Auth::PasswordService myPasswordService(myAuthService);
  std::vector<const Auth::OAuthService *> myOAuth;
}

void Session::configureAuth()
{
  myAuthService.setAuthTokensEnabled(true, "logincookie");
  myAuthService.setEmailVerificationEnabled(true);

  Auth::PasswordVerifier *verifier = new Auth::PasswordVerifier();
  verifier->addHashFunction(new Auth::BCryptHashFunction(7));
  myPasswordService.setVerifier(verifier);
  myPasswordService.setAttemptThrottlingEnabled(true);

  if (Auth::GoogleService::configured())
    myOAuthServices.push_back(new Auth::GoogleService(myAuthService));
}

const Auth::AuthService& Session::auth()
{
  return myBaseAuth;
}

const Auth::PasswordService& Session::passwordAuth()
{
  return myPasswords;
}

const std::vector<const Auth::OAuthService *>& Session::oAuth()
{
  return myOAuth;
}

The Wt::Auth::AuthService is configured to support "remember-me" functionality, and email verification.

The Wt::Auth::PasswordService needs a hash function to safely store passwords. You can actually define more than one hash function, which is useful only if you want to migrate to a new hash function while still supporting existing passwords. When a user logs in, and he is not using the "preferred" hash function, his password will be rehashed with the preferred one. In this example, we will use bcrypt which is included as a hash function in Wt::Auth.

We also enable password attempt throttling: this mitigates brute force password guessing attempts.

Finally, we also use one (but later, perhaps more) Wt::Auth::OAuthService classes. You need one service per identity provider. Until OpenIDConnect is supported by most providers, each provider requires a proprietary method to access identity information using the authorized OAuth2.0 token. In this case, we only add Google as an identity provider.

3) The user interface

We create a specialized Wt::WApplication which contains our authentication session, and instantiates a Wt::Auth::AuthWidget. This widget shows a login or logout form (depending on the login status), and also hooks into default forms for registration, lost passwords, and handling of email-sent tokens in URLs).

User interface
#include <Wt/WApplication>
#include <Wt/WContainerWidget>
#include <Wt/WServer>

#include <Wt/Auth/AuthWidget>
#include <Wt/Auth/PasswordService>

#include "model/Session.h"

class AuthApplication : public Wt::WApplication
{
public:
  AuthApplication(const Wt::WEnvironment& env)
    : Wt::WApplication(env),
      session_(appRoot() + "auth.db")
  {
    session_.login().changed().connect(this, &AuthApplication::authEvent);

    useStyleSheet("css/style.css");

    Wt::Auth::AuthWidget *authWidget
      = new Wt::Auth::AuthWidget(Session::auth(), session_.users(),
                                 session_.login());

    authWidget->addPasswordAuth(&Session::passwordAuth());
    authWidget->addOAuth(Session::oAuth());
    authWidget->setRegistrationEnabled(true);

    authWidget->processEnvironment();

    root()->addWidget(authWidget);
  }

  void authEvent() {
    if (session_.login().loggedIn())
      Wt::log("notice") << "User " << session_.login().user().id()
                        << " logged in.";
    else
      Wt::log("notice") << "User logged out.";
  }

private:
  Session session_;
};

The last part is our main function where setup the application server:

Application server setup
Wt::WApplication *createApplication(const Wt::WEnvironment& env)
{
  return new AuthApplication(env);
}

int main(int argc, char **argv)
{
  try {
    Wt::WServer server(argv[0]);

    server.setServerConfiguration(argc, argv, WTHTTP_CONFIGURATION);
    server.addEntryPoint(Wt::Application, createApplication);

    Session::configureAuth();

    if (server.start()) {
      Wt::WServer::waitForShutdown();
      server.stop();
    }
  } catch (Wt::WServer::Exception& e) {
    std::cerr << e.what() << std::endl;
  } catch (std::exception &e) {
    std::cerr << "exception: " << e.what() << std::endl;
  }
}

We would like to hear from you your first impressions, and if you are seeing things that are missing are blatantly wrong (or the hangman example isn’t working properly for you), better tell us now than later (once it is released)!

Tags:
9 comments
  • Posted by anonymous
  • 4 years ago
Hi. I would like to create a folder named using a user 's username when ever a new user registers. Is there an OnRegistration signal or something where I can grab the user's information, create a folder and save the details after the user has entered valid registration details and clecked the register button.
  • Posted by anonymous
  • 10 years ago
How can I use openID?
  • Posted by anonymous
  • 11 years ago
The links from this post are not working. :(
  • Posted by anonymous
  • 12 years ago
Is there any status update on the JWt version of this you can provide?
  • Posted by anonymous
  • 12 years ago
Very nice... going throw it right now. I'm trying to find the information about the different classes used in CSS so that I can play with it. Maybe you should put some info about that. Kudos!
  • Posted by anonymous
  • 13 years ago
Very good work! As always with Wt, a very good, flexible and extensible design. Kudos!
marco.m
  • Posted by anonymous
  • 13 years ago
Awesome work, thank you for providing such awesome tools but it would be better if there was a better documentation for Wt Auth :)
  • Posted by anonymous
  • 10 years ago
Agree
  • Posted by anonymous
  • 10 years ago

Contact us for more information
or a personalised quotation

Contact Us