First thoughts

Plugin architecture

We should provide a plugin architecture that makes it possible to easily plugin authorisation backends, such as

  • LDAP
  • NTLM
  • File based (xml, htpasswd, ...)
  • Jdbc-database (configurable jdbc connection param, table and fieldnames)
  • Centralized external webservices like openIdServer or an own OAuth conform AuthenticationServer)
  • Any custom back-end you might use in house (e.g. Schaubroeck Atlas Checkpoint)

Authentication wire format & protocol

Kauri should support:

  • HTTP Basic Authentication
    • based on a username and password
    • the authentication mechanism defined in the HTTP/1.0 specification
    • not a secure authentication protocol. User passwords are sent in simple base64 encoding (not encrypted), and the target server is not authenticated.
  • HTTP Digest Authentication
    • also authenticates a user based on a username and a password
    • the authentication is performed by transmitting the password in an encrypted form which is much more secure
  • HTTPS Client Authentication
    • end user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism
    • this mechanism requires the user to possess a Public Key Certificate (PKC)
  • credentials
    • simply supply username and password, e.g. through a form submit
  • OAuth - see http://oauth.net/
    • e.g. use case: one kauri app can access private data from another one (maybe even implicit through the km: protocol)
  • openID - see http://openid.net/
  • belgian eID -see http://eid.belgium.be/
  • Some safe "remember my last login" technique for automatic subsequent authentication. This should be configurable to only require actual re-authentication for a cvertain user from the same machine only once in a given period of time.

Authenticated user API

We should provide a clean and easy to use API to retrieve the "authenticated user" from a request and enable the retrieval of properties of that user,
making it possible to do something like this:

class MyRestlet extends Restlet {
    ...
    public void handle(Request request, Response response) {
	...
        User user = request.getAuthenticatedUser();
	Property prop = UserPropertyService.getProperty(user,"mypropkey");
	...
    }
    ...
}

Support for authenticated Client Calls

When calling upon restservice-dependencies we should be able to configure which authentication mechanisms the system can use when it is faced with a challenge response from that service.

Things that should be possible when forwarding the call:

  • use a new dedicated 'user' for that service
  • propagate the current user (will require knowledge of it's credentials, some SSO token, or maybe tapping into the oauth procedure again?)

Configuration

How can we configure which paths require authentication, and what kind of authentication ?

  • perhaps in the kauri.xml, e.g. <mount name="..." path"..." required-realm="authenticationrealm" />
  • or probably better: configure it in the routing ?

To identify the kind of authentication, we could define an authentication realm, with properties as 'tenant' and ...

Same remark for the client-calls: per called upon service we should be able to configure which authentication challenges are to be expected and how to deal with them.

Also, we should think about centralized configuration for auth-related stuff as local keystores, user-password stores, etc etc.

Remarks

Think about multi-tenancy support when implementing the kauri authentication layer.
Also note: If we would allow to use different virtual hosts for each tenant, the tenant property could be automatically injected in the authentication realm.