Generate Access Rules from Role Configuration

Description

Currently it's very cumbersome to change anything related to the access rules generated for the dispatcher since the locations to allow/deny are hard-coded into the templates. To add a rule you'd have to override the complete template.
So it would be useful if the locations to be restricted are extracted into parameter lists of the role configuration. You could then extend them with custom rules and the statements in the templates could be generated by iterating over these lists. To illustrate the idea:

A few random points:

  1. If the risk of accidentally deactivating the default list of critical paths is too high it should at least be possible to augment them with custom rules.

  2. It should probably be possible to remove restrictions for the selectors in any case since there might be cases where you actually want them accessible.

  3. It would be nice if the syntax for the rules would be generic enough so that either httpd or dispatcher rules could be generated from them (if someone feels more comfortable with the dispatcher.any configuration). This however is probably not so simple since the syntaxes of httpd and the dispatcher module would need to be converted between with even more risk of something not being generated as expected.

Gliffy Diagrams

Activity

Show:

Stefan Seifert October 11, 2017 at 3:45 PM

Stefan Seifert October 11, 2017 at 3:44 PM

this is implemented, together with some major refactorings:

  1. i decided to directly support both dispatcher filter rules and httpd allow/deny rules - and to use them in parallel for different usecases. with the latest additions in AEM dispatcher 4.2.0 (regex support, support for directly filtering for extensions, selectors etc.) it is much more easier to do the "security/anti-content-grabbing" filtering in dispatcher.any. i've left only controlling the access to the admin consoles in the httpd config.

  2. thus i introduced two new list variables with an object structure for defining the rules at dispatcher.filter and httpd.accessRestriction.locationFilter. see aem-dispatcher.yaml role file for a detailed description.

  3. i also added a bunch of additional parameters for making the dispatcher.any more configurable, e.g. for cache and invalidation rules. documented in aem-dispatcher.yaml

  4. and last but not least i restructured most of the dispatcher role config parameter name to clearly distinguish between httpd (targeting apache and vhost files) and dispatcher (targeting dispatcher config files). a mapping table for the parameters is included in the 0.x -> 1.x migration guide https://wcm-io.atlassian.net/wiki/x/AQDRAw

  5. i added sensible defaults to all parameters matching the config from the 0.x roles, and updated with some new aspects defined in the dispatcher config examples from latest AEM dispatcher releases

Stefan Seifert October 10, 2017 at 3:25 PM

after playing around with different approaches for declaring the filter rules (and solving ) martins apporach from the ticket description works as well, and is more flexible then my approach from my last comment.

but before we start inventing a new syntax for declaring filter rules, we might also take over excactly the same syntax as used in dispatcher.any files:
https://docs.adobe.com/docs/en/dispatcher/disp-config.html#par_134_32_0009

and just transform it to apache httpd config rules (we can write a custom handlebars helper for this in the conga aem plugin). maybe add an extra support for the admin access filter rules, which do not block in general, but allow access from certain ip ranges.

Stefan Seifert August 15, 2017 at 3:22 PM
Edited

my proposal would be something like this - add a new set of parameters to the dispatcher role configurations. we cannot use complex structures as CONGA parameters, only nested maps.

no patterns are allowed for locations or selectors (can be done with custom http config). the strings are escaped or converted into a pattern in the template. locations are checked with "location" directive, selectors if the URI contains the given string at any position.

normaly the list of deny rules is not touched in the environment (it's the list maintained in the role and is updated if new dangerous selectors need to be added). iwth the allow variable it's possibel to override a deny and allow it although its included in the deny list.

from the sling parameters only sling.defaultJsonOutput is relevant for the dispatcher role (the others are relevant for the aem role). if this is set to false, variants like .999.json or .-1.json or .inifinty.json or .tidy.json are denied.

for /dispatcher there is additional special logic depending on dispatcher.allowFlushFrom and dispatcher.allowFlushFromHost.

this should be done together with WDCONGA-14.

Stefan Seifert July 21, 2017 at 3:32 PM

this is a good idea.

some deny rules are directly in relation to features in AEM that can be switched on/off - e.g. allowing access to .json or .xml view of nodes or not. if they are allowed on httpd/dispatcher, the feature should be activated in the Sling GET Servlet as well and vice versa.

perhaps we split up this whole selector configuration in a set of feature flags for specific features, and a list of more generic allow/deny patterns which can be overwritten or extended.

for the different pattern formats in dispatcher and httpd: i suppose it's easy to automatically match dispatcher->httpd, but not the other way round. i we want to do this automatic we would need to limit ourselves to the dispatcher rule syntax.

Fixed

Details

Assignee

Reporter

Components

Priority

Created July 20, 2017 at 12:52 PM
Updated November 13, 2017 at 2:58 PM
Resolved October 11, 2017 at 3:44 PM
Loading...