SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

This is about creating service users and setting ACLs for SLING-5355.
I think it's easier to discuss these general principles here.

Carsten wrote there:

> I would prefer a solution which is processed by the tool processing the provisioning model
> and then creating "content" which is installed in the repository. So it's a one time thing -
> done at build time.

You will need a runtime component as well - to install content, you
have to wait for the content repository to be available, and also wait
for any required node types to be available (see the "additional
constraints" that I added to the ticket's requirement) if you want to
create the required paths.

So, once you have those mechanisms that can create users and change
ACLs at runtime, why would they be safer that OSGi configs? I think
I'll need a very concrete example of what you are suggesting to be
convinced that it's better than the current config-based mechanism.

-Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Oliver Lietz <ap...@oliverlietz.de>]

On Wednesday 06 January 2016 14:34:04 Bertrand Delacretaz wrote:
> Hi,
> 
> On Wed, Jan 6, 2016 at 11:54 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> > On Wednesday 06 January 2016 11:33:03 Bertrand Delacretaz wrote:
> >>... a) tweak the provisioning model tools so that a new ProvisioningModel
> >>
> >> service makes the content of :additional model sections available as
> >> unprocessed full text at runtime
> > 
> > this is for auditing, right? Does it really help if ACLs can be changed in
> > several ways?...
> 
> Yes the idea is that one can later check if their instance is still
> compliant with the ACL setup of the provisioning model. Mostly to
> check that those ACLs have not been removed or changed by other means.
> I'm not planning to implement this right now but want to leave it
> open.
> 
> >>... b) implement a component to process :basetree additional sections,
> >>
> >> with a micro-language to define the initial paths (with node types) to
> >> create for requirement 2)
> > 
> > Does it need to be a _new_ micro-language or can we use the existing JSON
> > and XML formats?...
> 
> Which existing languages exactly?

The XML (incl. JCR SystemView) and JSON formats used by Content Loader:

http://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#xml-descriptor-files

> At this point I'm thinking of a dead simple, one line per path format like
> 
> CREATE [sling:Folder] /var/discovery[nt:unstructured]/some/subpath
> 
> to mean "create the specified path, defaulting to sling:Folder unless
> bracketed nodetypes indicate otherwise.
> 
> I think it matches the existing provisioning model "flavor" and that's
> simple to implement.
> 
> > ...Please make sure we have an "API" for these components which can be
> > used when not using the provisioning model....
> 
> Yes, I'm aiming for that and it's already the case for what's under
> contrib/extensions/acldef - feel free to yell if you see something
> missing.

Thanks, Bertrand.

O.

> Thanks for the feedback,
> -Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Jan 6, 2016 at 11:54 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> On Wednesday 06 January 2016 11:33:03 Bertrand Delacretaz wrote:
>>... a) tweak the provisioning model tools so that a new ProvisioningModel
>> service makes the content of :additional model sections available as
>> unprocessed full text at runtime
>
> this is for auditing, right? Does it really help if ACLs can be changed in
> several ways?...

Yes the idea is that one can later check if their instance is still
compliant with the ACL setup of the provisioning model. Mostly to
check that those ACLs have not been removed or changed by other means.
I'm not planning to implement this right now but want to leave it
open.

>>... b) implement a component to process :basetree additional sections,
>> with a micro-language to define the initial paths (with node types) to
>> create for requirement 2)
>
> Does it need to be a _new_ micro-language or can we use the existing JSON and
> XML formats?...

Which existing languages exactly?

At this point I'm thinking of a dead simple, one line per path format like

CREATE [sling:Folder] /var/discovery[nt:unstructured]/some/subpath

to mean "create the specified path, defaulting to sling:Folder unless
bracketed nodetypes indicate otherwise.

I think it matches the existing provisioning model "flavor" and that's
simple to implement.

> ...Please make sure we have an "API" for these components which can be used when
> not using the provisioning model....

Yes, I'm aiming for that and it's already the case for what's under
contrib/extensions/acldef - feel free to yell if you see something
missing.

Thanks for the feedback,
-Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Oliver Lietz <ap...@oliverlietz.de>]

On Wednesday 06 January 2016 11:33:03 Bertrand Delacretaz wrote:
> Hi,

Hi,

> On Wed, Jan 6, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org> 
wrote:
> > ...Perfect :) ..
> 
> Ok, glad that we agree!
> 
> So how about the following implementation based on the above 3 requirements:
> 
> a) tweak the provisioning model tools so that a new ProvisioningModel
> service makes the content of :additional model sections available as
> unprocessed full text at runtime

this is for auditing, right? Does it really help if ACLs can be changed in 
several ways?

> b) implement a component to process :basetree additional sections,
> with a micro-language to define the initial paths (with node types) to
> create for requirement 2)

Does it need to be a _new_ micro-language or can we use the existing JSON and 
XML formats?

> c) implement a component to process :accesscontrol sections using the
> SLING-5355 ACL defs language (almost done in the acldefs/oak-jcr
> module)
> 
> d) later, implement a validation of the :accesscontrol against the
> current repository state
> 
> WDYT?

Please make sure we have an "API" for these components which can be used when 
not using the provisioning model.

O.

> -Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Jan 6, 2016 at 11:41 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote
>> b) implement a component to process :basetree additional sections...

>> c) implement a component to process :accesscontrol sections...

> ...the only comment I have is whether we really need
> to separate between b) and c).
> But maybe that makes sense as you can specify paths in b) without ACLs
> in c) and vice versa....

I'm not 100% sure either...maybe I'll wrap both things into a
:contentsetup provisioning model section , I'll see how that works
when implementing and we can review when that's done.

-Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> Hi,
> 
> On Wed, Jan 6, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...Perfect :) ..
> 
> Ok, glad that we agree!
> 
> So how about the following implementation based on the above 3 requirements:
> 
> a) tweak the provisioning model tools so that a new ProvisioningModel
> service makes the content of :additional model sections available as
> unprocessed full text at runtime
> 
> b) implement a component to process :basetree additional sections,
> with a micro-language to define the initial paths (with node types) to
> create for requirement 2)
> 
> c) implement a component to process :accesscontrol sections using the
> SLING-5355 ACL defs language (almost done in the acldefs/oak-jcr
> module)
> 
> d) later, implement a validation of the :accesscontrol against the
> current repository state
> 

Sounds like a plan - the only comment I have is whether we really need
to separate between b) and c).
But maybe that makes sense as you can specify paths in b) without ACLs
in c) and vice versa.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Jan 6, 2016 at 10:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...Perfect :) ..

Ok, glad that we agree!

So how about the following implementation based on the above 3 requirements:

a) tweak the provisioning model tools so that a new ProvisioningModel
service makes the content of :additional model sections available as
unprocessed full text at runtime

b) implement a component to process :basetree additional sections,
with a micro-language to define the initial paths (with node types) to
create for requirement 2)

c) implement a component to process :accesscontrol sections using the
SLING-5355 ACL defs language (almost done in the acldefs/oak-jcr
module)

d) later, implement a validation of the :accesscontrol against the
current repository state

WDYT?

-Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> Hi Carsten,
> 
> On Wed, Jan 6, 2016 at 9:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ....we should keep constraints and conclusions separate!...
> 
> So let's try to focus on the high-level requirements, I see this:
> 
> 1) Create service users and set their ACLs as defined in the Sling
> instance's provisioning model.
> 
> 2) Create initial paths like /var/discovery, so that ACLs can be set on them.
> 
> 3) Make the full text of the ACL definitions available at runtime for
> auditing purposes (see Michael Marth's Dec.17 comment in SLING-5355).
> Also useful for upgrades where merging with conflict detection is
> needed.
> 
> Do we agree on this?
> 
Perfect :)
Thanks Bertrand

Carsten
 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi Carsten,

On Wed, Jan 6, 2016 at 9:56 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> ....we should keep constraints and conclusions separate!...

So let's try to focus on the high-level requirements, I see this:

1) Create service users and set their ACLs as defined in the Sling
instance's provisioning model.

2) Create initial paths like /var/discovery, so that ACLs can be set on them.

3) Make the full text of the ACL definitions available at runtime for
auditing purposes (see Michael Marth's Dec.17 comment in SLING-5355).
Also useful for upgrades where merging with conflict detection is
needed.

Do we agree on this?

-Bertrand

Re: SLING-5355 - configs vs. content for ACLs and service users

[Carsten Ziegeler <cz...@apache.org>]

Sorry, but I don't agree on the new added constraints and their
conclusion - we should keep constraints and conclusions separate!


- AC1: Waiting for content paths: not all ACLs can be applied
immediately when the SlingRepository service starts: for this we'd need
to create paths that don't exist yet, and the nodetypes of those paths
might not have been defined yet, as any bundle can supply additional
node types. This means waiting for the path creation to succeed before
proceeding, so we might as well wait for the paths to be created by
content installations

Again, as already explained there is no content to be installed by
bundles. And with service users, the bundles can't create the path as
they don't have the rights. For example, discovery reads/writes at
/var/discovery. But discovery has no rights to create /var. So again,
who is creating this? Requiring additional content for this is wrong and
way too complex.
We must not forget, that today these bundles are self contained. They
work out of the box, regardless if the configuration (path) for them is
changed or not as they have admin power and can do whatever is
necessary. With service users we remove this. But still it must be
simple to use this approach. Someone else needs to create /var for
discovery. Nodetypes should be no issue, they can be changed later on.

- AC2: The mechanism must work for any launchers, not just the Sling
Launchpad - so it cannot be just a build-time thing.

Well, maybe "build time" was a wrong term from me. What I mean is that
it does not have to be a runtime thing in the sense that it must not be
something evaluated when the OSGi framework is started. For example, if
we generate something out of the information, this generation can be run
within our maven plugin but also by any other launcher. That's easy.
Concluding from this requirement that it must be a service running in
the framework is wrong. There are many options.

- AC3: The full text of the ACL definitions must be available at
runtime. This allows for example checking later that a Sling instance is
still configured according to those ACL definitions.

Again, this is hinting at a particular implementation/solution for the
problem. With the current approach this definition is an OSGi
configuration which can be changed at runtime. So what purpose does such
a check have?

Regards
Carsten



 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: SLING-5355 - configs vs. content for ACLs and service users

[Carsten Ziegeler <cz...@apache.org>]

Bertrand Delacretaz wrote
> Hi,
> 
> This is about creating service users and setting ACLs for SLING-5355.
> I think it's easier to discuss these general principles here.
> 
> Carsten wrote there:
> 
>> I would prefer a solution which is processed by the tool processing the provisioning model
>> and then creating "content" which is installed in the repository. So it's a one time thing -
>> done at build time.
> 
> You will need a runtime component as well - to install content, you
> have to wait for the content repository to be available, and also wait
> for any required node types to be available (see the "additional
> constraints" that I added to the ticket's requirement) if you want to
> create the required paths.

We already have this runtime component: the jcr content loader. We could
simply create a bundle at build time containing the content for all
services users, and the content for the ACLs and are done.
This also solves the problem of who is creating the paths.

Take a look at what we have today, for example the Sling event bundle
(but the same is true for others as well): today these bundles use an
admin user to create the initial path. They don't have any content as
the only requirement these bundles have is an existing path with ACLs
allowing them to operate on this content.

With creating a content bundle we can at least ensure that once this
content is installed everything is in place. With the current mechanism
we can't ensure anything and as every piece is added at a different time
this becomes much harder.

In any case, those bundles need to express someone that they depend on
someone else to create the content, the ACLs and the service user.
Regardless of what we use this is missing.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: SLING-5355 - configs vs. content for ACLs and service users

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Tue, Jan 5, 2016 at 4:48 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...This is about creating service users and setting ACLs for SLING-5355...

FYI I have thought a bit more about this and broadened the scope a bit
to include other things that need to be initialized in the content
repository, and make the core of this independent form Sling. See
SLING-5449 for details, and if there are high-level things to discuss
we can do this here.

-Bertrand