How to authorise access to resources within the InternetWide Identiy Framework?

The InternetWide Architecture works towards an infrastructure with a Bring Your Own IDentity concept to give end users optimal control over their online presence and privacy.

As with any Identity Framework, the two concepts at play are authentication and authorisation, described below. These are mutually enforcing, but different concepts.

Relation to Authentication

The process of authentication delivers validated identities for remote peers. To a mail server it might prove who the mail client is, for example. Knowing who a remote peer is does not say much about the rights assigned to him, so an additional mechanism is needed: authorisation maps identities onto access rights. Note that this only makes sense for valid identities, which is why authorisation is commonly preceded by authentication. Given the tight coupling, it is no surprise that many confuse the two, but they are really (quite) distinct processes!

Resources and Access Modes

In general, we speak of resources that may be accessed in a certain mode for a certain identity.

With resources, we mean the index, page, file, object, setting, ... that we intend to access.

The mode is the kind of access that we desire, for instance for the addition or removal of resources; for reading or writing them; for listing the contents of an index, and so on.

The identity under which this is done may simply be the authenticated identity, but it is also possible to act on behalf of another identity; for instance, authorisation may be granted to for a group of which the validated identity is a member.

In our formalisms, we describe identities as a DoNAI, resources as a UUID and modes are single-character flags. We standardise certain forms and values, and leave others open for local extension.

Access Control Lists

An ACL determines the rights assigned to various users, often in the form of a pattern. These patterns make it simple to specify rights in a general manner, such as for all domain users instead of separately for each individual user. Such patterns help to improve both the user experience and processing speed.

ACLs will usually be incorporated as part of the authorisation system, so as to avoid the need to ask many questions if one would suffice. This means that our upcoming ACL formalisms can be incorporated without changing the software for services that rely on our authorisation mechanism.

The conceptual model contains more details about the information in our ACLs.

Diameter (or RADIUS)

The protocol over which authorisation questions are asked is either Diameter or RADIUS. Note that we are advising to already use authorisation software that supports both, so as to simplify future extensions. This means that Diameter can be used if so desired. An advantage of Diameter for service designers is that it runs over SCTP, where resends are not required, and where offline status of an authorisation service can easily be detected. It is also possible to have encryption of the SCTP connection setup with DTLS, and avoid expensive mechanisms such as RadSec that encrypt connections for each individual request.