[Standards] Veto on "Privileged Entity"
dave at cridland.net
Tue Dec 16 16:12:00 UTC 2014
At the last Council meeting, I entered a position of -1 concerning
In order to explain my position better, it's worth examining how
authorization systems currently model the world. I'm going to use XACML
terms here, although in practise these are industry terms of art in most
In any access decision, there are a number of "subjects" - at least one,
the "Access Subject", and possibly others (an "Authorizing Subject",
perhaps). The decision is whether or not to allow the "Access Subject" to
perform an "Action" on a "Resource".
The decision is required, and enforced, by a Policy Enforcement Point, or
PEP. The PEP gathers information, and sends it to a Policy Decision Point,
or PDP. The PDP returns a decision. There are also Policy Information
Points, which act as information gatherers - typically these might be
querying LDAP directories or SQL databases.
For our purposes, the XMPP server is mostly considered here as acting as a
A key issue is that the PDP can be (and often is) external to the PEP, and
centralized. There are standards for this (such as XACML) which allow both
policies to be expressed and also define PEP->PDP wire protocols. Most
modern standards are now focussed on Attribute Based Access Control, which
are particularly fine-grained.
Currently we have three explicit, and one implicit, authorization
mechanisms in XMPP:
1) The Affiliations of MUC and PubSub. This is a Role Based Access Control
mechanism with fixed roles.
2) The Security Information Object mechanism of XEP-0258, used for
protective marking schemes. This is, again, a Role Based Access Control
mechanism of sorts, with definable Roles. Interestingly, this has a
3) MUC Hats, which is a fairly straightforward Role Based Access Control
system using user-defined Roles. Nobody, so far as I know, implements this,
but it was defined on the perceived need of finer-grained access control to
4) The implicit permissioning of Rosters and vCards, wherein the owner has
access and nobody else.
All of these are fairly inflexible, do not integrate with external PDPs,
and are all RBAC.
The ProtoXEP in question was aiming at defining another, new, RBAC system
which also would have a fixed role, fixed policy.
Although the outcome is desirable - that is, replacing (4) above with a
more flexible system - I'm concerned that this is patching a specific
problem rather than addressing the broader view of where the state of the
art in access control is.
Instead, I think we should take a step back and try to cast our
authorization model in the form the current ABAC standards can work with;
ideally getting us to a point where enterprise PDPs could be used if needed
to provide centralized policy control.
In particular, this means clearly defining the resources involved, the
actions available - both generic actions and in some cases specialist ones
- and then look at how we can generically authorize subjects.
The result of this might be "woah, this is way too difficult", but I'd
rather say that after exploring the are properly - (3) above has done much
of this work already for MUC, so clearly there is *some* interest.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards