On 16 Dec 2014 18:03, "Goffi" <[email protected]> wrote: > even if I understand your point of view, I have the feeling to see the famous > XKCD strip: let's do a new standard which cover everyones use cases > (situation: 15 competing standards) ! >
That's actually what I'm trying to avoid; we currently have lots of fractional solutions, and no real standard. > The XACML protocol is more than 150 pages, I can't see any XEP adapting this > to XMPP coming before years, and even if we see that one day, I don't think > anybody will implement that (for the record: we are proposing XEPs to have an > external implementation of PubSub because to my knowledge none of the server > has a complete implementation, so we can't bring a decent microbloging system > to XMPP; if XEP-0060 is not fully implemented, what about a potentially larger > XEP ?) XACML is indeed huge, and there are several specifications involved. I'm not suggesting we make that mandatory, merely that we make that possible, by using a model that is compatible, and using the same terms of art used in the field. At least, where possible. > The Privileged Entity protoXEP is quite simple and do the job, it can be > implemented in a couple of hours in most servers, and it solve several issues. > In addition if some day we actually see an XACML implementation with XMPP, we > can still obsolete the Privileged Entity. > Yes, the question is whether we can find a mechanism which is both this simple, and also fits the model that other systems use already. > So I think putting a veto on this is really severe, and will delay > microbloging implementations in XMPP for years. We are curently several > projects stucked with current state of PubSub and PEP implementations, and > having an external PEP service is an option generic and available quickly. > I'd be very interested in knowing what's missing here. I'm sure other server developers would be as well. > I'm curious to see some other opinions on this subject. > As am I. A veto position need not be permanent, and I'm hoping we can find the beginning of a solution, and agree a path forward, instead of simply blocking progress. > Cheers > Goffi > > Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit : > > Folks, > > > > At the last Council meeting, I entered a position of -1 concerning > > Privileged Entity: > > > > http://xmpp.org/extensions/inbox/privilege-component.html > > > > 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 > > cases. > > > > 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 > > PEP. > > > > 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 > > configurable policy. > > > > 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 > > chatrooms. > > > > 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. > > > > Dave. >
