You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2015/12/07 14:22:57 UTC
Re: Removing loginAdministrative, how to test that, and service
username conventions
Hi,
On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...do we have a solution now on how to
> define the service user and ACLs in the provisioning model?...
I'm hoping to find time to work on this soon, for now I had a look at
the ideas in JCRVLT-61 and chatted with Robert and we came up with the
following suggestions for two simple mini-languages that we can use in
our provisioning model:
a) Creating service users (this one is definitely a micro-language ;-)
# comments and blank lines are supported of course
create service user printService,someService
delete service user printService,anotherService
b) Setting ACLS from our provisioning model:
# comments and blank lines are supported of course
set ACL on /libs,/apps with glob */install/*
remove * for user1,user2
allow jcr:read for user1,user2
deny jcr:write for user2
deny jcr:lockManagement for user1
end
Both mini-languages should be implemented in their own modules so as
to be reusable in other contexts, automated tests for example, and
maybe JCRVLT-61 if the Oak folks are interested.
I have created https://issues.apache.org/jira/browse/SLING-5355 for
this, if someone needs it and can help feel free to jump in!
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
Ok, I just noticed I replied to a super old thread because my Email app decided to surface it as if it were new :D
Cheers,
Alex
> On 01.10.2018, at 16:19, Alexander Klimetschek <ak...@adobe.com.INVALID> wrote:
>
> Hi Marius,
>
> AFAICS, what you describe below is exactly my @ServiceUser annotation, just different names and a different syntax for the ACLs :)
>
> Cheers,
> Alex
>
> On 08.12.2015, at 08:09, Marius Petria <mp...@adobe.com> wrote:
>> I do not have a precise use case right now other than obtaining a “content access contract” that can be used by tools. Basically, I just wanted to emphasize that service requirements in code and install instructions in the provisioning model are two sides of the same coin and we might need both.
>>
>> Alexander Klimetschek’s ServiceUser annotation is something close to what I call service requirements but it goes too concrete by embedding ACL commands like (allow /content/dam jcr:read) and by looking to define service users rather than services. A similar annotation @ServiceRequirement could be used for expressing requirements.
>>
>> @ServiceRequirement(permissions = { "/content/mystuff jcr:read”})
>> private static final String SERVICE_NAME = “my-service";
>> Session session = repository.loginService(SERVICE_NAME, null);
>>
>> Then something like the permissionChecker can be called at activate time, or just in webconsole when listing the service user mappings. These annotations can be also used to auto generate service users and ACLs but that should not be automatically installed (except for testing) as the actual users and ACLs should be installed explicitly by the provisioning model.
>>
>> Now, imagine I have a bundle that is annotated with @ServiceRequirements then I can just install it in two ways:
>> - for testing, I install it with a flag autoGenerateServiceUser=true. This will eliminate the need of defining any additional service user installation in a provisioning model just for that test and the bundle is standalone.
>> - for production, I install with autoGenerateServiceUser=false and maybe validateServiceUser=true which will validate against the actual mapping and repository.
>> I am not sure how these switches will be specified though this is just a high level wish :).
>>
>>
>>
>> Marius
>>
>
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Alexander Klimetschek <ak...@adobe.com.INVALID>.
Hi Marius,
AFAICS, what you describe below is exactly my @ServiceUser annotation, just different names and a different syntax for the ACLs :)
Cheers,
Alex
On 08.12.2015, at 08:09, Marius Petria <mp...@adobe.com> wrote:
> I do not have a precise use case right now other than obtaining a “content access contract” that can be used by tools. Basically, I just wanted to emphasize that service requirements in code and install instructions in the provisioning model are two sides of the same coin and we might need both.
>
> Alexander Klimetschek’s ServiceUser annotation is something close to what I call service requirements but it goes too concrete by embedding ACL commands like (allow /content/dam jcr:read) and by looking to define service users rather than services. A similar annotation @ServiceRequirement could be used for expressing requirements.
>
> @ServiceRequirement(permissions = { "/content/mystuff jcr:read”})
> private static final String SERVICE_NAME = “my-service";
> Session session = repository.loginService(SERVICE_NAME, null);
>
> Then something like the permissionChecker can be called at activate time, or just in webconsole when listing the service user mappings. These annotations can be also used to auto generate service users and ACLs but that should not be automatically installed (except for testing) as the actual users and ACLs should be installed explicitly by the provisioning model.
>
> Now, imagine I have a bundle that is annotated with @ServiceRequirements then I can just install it in two ways:
> - for testing, I install it with a flag autoGenerateServiceUser=true. This will eliminate the need of defining any additional service user installation in a provisioning model just for that test and the bundle is standalone.
> - for production, I install with autoGenerateServiceUser=false and maybe validateServiceUser=true which will validate against the actual mapping and repository.
> I am not sure how these switches will be specified though this is just a high level wish :).
>
>
>
> Marius
>
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Marius Petria <mp...@adobe.com>.
On 12/8/15, 4:16 PM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>The require method throws an Exception if the requested permissions
>are not granted.
>
>Using this in a bundle Activator or in a component's activate() method
>causes those activations to fail if permissions are missing, with
>clear messages in the logs to help fix that.
>
>Would that work for your use cases?
I do not have a precise use case right now other than obtaining a “content access contract” that can be used by tools. Basically, I just wanted to emphasize that service requirements in code and install instructions in the provisioning model are two sides of the same coin and we might need both.
Alexander Klimetschek’s ServiceUser annotation is something close to what I call service requirements but it goes too concrete by embedding ACL commands like (allow /content/dam jcr:read) and by looking to define service users rather than services. A similar annotation @ServiceRequirement could be used for expressing requirements.
@ServiceRequirement(permissions = { "/content/mystuff jcr:read”})
private static final String SERVICE_NAME = “my-service";
Session session = repository.loginService(SERVICE_NAME, null);
Then something like the permissionChecker can be called at activate time, or just in webconsole when listing the service user mappings. These annotations can be also used to auto generate service users and ACLs but that should not be automatically installed (except for testing) as the actual users and ACLs should be installed explicitly by the provisioning model.
Now, imagine I have a bundle that is annotated with @ServiceRequirements then I can just install it in two ways:
- for testing, I install it with a flag autoGenerateServiceUser=true. This will eliminate the need of defining any additional service user installation in a provisioning model just for that test and the bundle is standalone.
- for production, I install with autoGenerateServiceUser=false and maybe validateServiceUser=true which will validate against the actual mapping and repository.
I am not sure how these switches will be specified though this is just a high level wish :).
Marius
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Dec 8, 2015 at 9:28 AM, Marius Petria <mp...@adobe.com> wrote:
> ...2. Development definition of services and their requirements (defined by a developer)
> - this a a bundle concern and is a definition of services (not of users) and their needs
> - it does not say how to get there (create user, add acls, …) just what it needs
> - someServiceName require read on somePath
> - someServiceName optional write on somePath...
How do you see this working?
One simple scenario that comes to mind is a utility that verifies that
specific permissions are granted:
final Session s = repository.loginService(...);
permissionsChecker.forSession(s)
.require("jcr:all", somePath)
.require("jcr:read", anotherPath)
The require method throws an Exception if the requested permissions
are not granted.
Using this in a bundle Activator or in a component's activate() method
causes those activations to fail if permissions are missing, with
clear messages in the logs to help fix that.
Would that work for your use cases?
-Bertrand
Re: Removing loginAdministrative, how to test that, and service
username conventions
Posted by Marius Petria <mp...@adobe.com>.
Hi all,
I think the current proposal makes sense and deals with the deployment concerns of service users. Would it make sense to express also the development requirements for services? I know that has been discussed over and over again but I wonder if instead of choosing one variant over another we could actually have both.
1. Deployment definition of service users and ACLs (defined by a "deployer”)
- this is a provisioning concern and is what Bertrand is proposing (create user, add remove ACLs)
2. Development definition of services and their requirements (defined by a developer)
- this a a bundle concern and is a definition of services (not of users) and their needs
- it does not say how to get there (create user, add acls, …) just what it needs
- someServiceName require read on somePath
- someServiceName optional write on somePath
Some advantages of a separate specification of required capabilities would be
1. The developer focuses only on what its code needs, not on how to install them (this becomes smoking of "content access API").
2. A tool can pick up the development requirements and install them (this can be used at least for testing).
3. A tool can validate the mapping between someServiceName and someServiceUser to be according to the requirements. This can be specifically useful in upgrades you will have a way to see it the repo has what it needs for the new code to work properly.
Marius
On 12/7/15, 3:22 PM, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>Hi,
>
>On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> ...do we have a solution now on how to
>> define the service user and ACLs in the provisioning model?...
>
>I'm hoping to find time to work on this soon, for now I had a look at
>the ideas in JCRVLT-61 and chatted with Robert and we came up with the
>following suggestions for two simple mini-languages that we can use in
>our provisioning model:
>
>a) Creating service users (this one is definitely a micro-language ;-)
>
> # comments and blank lines are supported of course
> create service user printService,someService
> delete service user printService,anotherService
>
>b) Setting ACLS from our provisioning model:
>
> # comments and blank lines are supported of course
> set ACL on /libs,/apps with glob */install/*
> remove * for user1,user2
> allow jcr:read for user1,user2
>
> deny jcr:write for user2
> deny jcr:lockManagement for user1
> end
>
>Both mini-languages should be implemented in their own modules so as
>to be reusable in other contexts, automated tests for example, and
>maybe JCRVLT-61 if the Oak folks are interested.
>
>I have created https://issues.apache.org/jira/browse/SLING-5355 for
>this, if someone needs it and can help feel free to jump in!
>
>-Bertrand