[Freeipa-devel] URI in HBAC - design page

[Fraser Tweedale]

On Thu, Mar 24, 2016 at 01:09:24PM +0100, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 11:39:17AM +1000, Fraser Tweedale wrote:
> >
> > Further to Rob's points, what about including the method being used
> > (HTTP GET/POST/PUT/PATCH)?  In a RESTful world this seems like an
> > important aspect to include.
> > 
> > How deep does this rabbit-hole go? :)
> 
> The work, while focused primarily on web use-cases, should be usable
> outside of HTTP protocol. The rabbit hole might include questions
> about mapping FTP commands into some sensible list of methods that
> could be easily managed. In his work Lukáš seemed concerned by DENY
> rules not being supported (were removed from IPA), hence his regexp
> proposal with negative lookaheads to avoid
> 
> 	/		all users
> 	/admin		admins
> 
> where of course both URLs would match for access to /admin/edit but
> the longer one should win, thus serving as DENY.
> 
> For FTP that has the potential of having to list looooong list of
> commands:
> 
> 	long-list-of-all-cmds-except-write-cmds		/	all users
> 	long-list-of-write-commands			/	admins
> 
> If we could specify
> 
> 	*						/	all users
> 	long-list-of-write-commands			/	admins
> 
> and the situation was not considered as introduction of DENY
> mechanism, it might be more feasible. We might still want to have
> "metacommands" like 'FTP:read', 'FTP:write' to group the underlying
> commands for easy maintenance and presentation.
> 
> My preference would be not to do the methods at this time but have
> the data structured in such a way that it's easy to extend later.
> 
This story:

  ``
  As an administrator, I want to allow any user to "GET /posts" and
  "GET /posts/\w+" but only users who are members of group "authors"
  to "POST /posts" or "(PUT|DELETE) /posts/\w+"
  ''

will be the very first story if we release without method support.
IMO it is too obvious and important a thing to omit from the initial
implementation.

Cheers,
Fraser