jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Seidel. Robert" <Robert.Sei...@aeb.de>
Subject AW: Users and groups - Access control - Active Directory
Date Tue, 08 Feb 2011 15:05:42 GMT
Hi Tomás,

Either you give him all rights with jcr:all, or you can try with jcr:read && jcr:write
&& jcr:readAccessControl && jcr:modifyAccessControl. I'm not sure if jcr:write
is really necessary if the user should only create new users and give them the necessary privileges.

Here is the content from the specification (JSR 283 page 226/227):

A repository must support the following standard privileges identified by the
string constants of javax.jcr.security.Privilege:
. jcr:read: The privilege to retrieve a node and get its properties and their
values.
. jcr:modifyProperties: The privilege to create, remove and modify the
values of the properties of a node.
. jcr:addChildNodes: The privilege to create child nodes of a node.
. jcr:removeNode: The privilege to remove a node.
. jcr:removeChildNodes: The privilege to remove child nodes of a node.
In order to actually remove a node requires jcr:removeNode on that node
and jcr:removeChildNodes on the parent node. The distinction is
provided in order to distinguish implementations that internally model a
"remove" as a "delete" from those that model it as an "unlink". A
repository that uses the "delete" model can have jcr:removeChildNodes
in every access control policy, so that removal is effectively controlled by
jcr:removeNode. Conversely, a repository that uses the "unlink" model
can have jcr:removeNode in every access control policy.
. jcr:write: An aggregate privilege that contains:
o jcr:modifyProperties
o jcr:addChildNodes
o jcr:removeNode
o jcr:removeChildNodes
. jcr:readAccessControl: The privilege to read the access control settings
of a node.
. jcr:modifyAccessControl: The privilege to modify the access control
settings of a node.
. jcr:lockManagement: The privilege to lock and unlock a node (see §17
Locking).
. jcr:versionManagement: The privilege to perform versioning operations
on a node (see §15 Versioning).
227
. jcr:nodeTypeManagement: The privilege to add and remove mixin node
types and change the primary node type of a node (see §10.10 Node Type
Assignment).
. jcr:retentionManagement: The privilege to perform retention
management operations on a node (see §20 Retention and Hold).
. jcr:lifecycleManagement: The privilege to perform lifecycle operations
on a node (see §18 Lifecycle Management).
. jcr:all: An aggregate privilege that contains:
o jcr:read
o jcr:write
o jcr:readAccessControl
o jcr:modifyAccessControl
o jcr:lockManagement
o jcr:versionManagement
o jcr:nodeTypeManagement
o jcr:retentionManagement
o jcr:lifecycleManagement
Whether a privilege is abstract is an implementation variant, with the exception
that jcr:all is never an abstract privilege. For example, a repository unable to
separately control the abilities to add child nodes, remove child nodes, and set
properties could make jcr:modifyProperties, jcr:addChildNodes, and
jcr:removeChildNodes abstract privileges within the aggregate privilege
jcr:write.
Similarly, whether any one of these privileges is aggregate is an implementation
variant, with the exception that jcr:write and jcr:all are always aggregate
privileges.
A repository should also add all implementation-defined privileges to jcr:all.
The standard privilege names are defined as expanded form JCR names in string
constants of javax.jcr.security.Privilege.

Kindly Regards, Robert

-----Ursprüngliche Nachricht-----
Von: Tomás Temprano [mailto:ttemprano@Toyota.com.ve] 
Gesendet: Dienstag, 8. Februar 2011 15:55
An: users@jackrabbit.apache.org
Betreff: RE: Users and groups - Access control - Active Directory

Hi Robert.

Can you point me in the right direction for this?

>> From what I can see the default admin user in Jackrabbit is the only 
>> user with permissions to create new users...

>That's the situation in a new repository. However you can create a user, and give him
all necessary privileges to create users.

What permissions should I grant to the "autocreator" user?

I do not wan't to use the "admin" user for this task since the credentials will most likely
be hardcoded, so I will create a user that only has permissions to create new repository users.

Thank you,
Tomas.

-----Mensaje original-----
De: Seidel. Robert [mailto:Robert.Seidel@aeb.de] 
Enviado el: Lunes, 31 de Enero de 2011 09:05 a.m.
Para: users@jackrabbit.apache.org
Asunto: AW: Users and groups - Access control - Active Directory

Hi,

> From what I can see the default admin user in Jackrabbit is the only 
> user with permissions to create new users...

That's the situation in a new repository. However you can create a user, and give him all
necessary privileges to create users.


> I find the lack of howtos and best practices info is really 
> frustrating. I feel like I'm about to throw in the towel...

I've invested a lot of time too to read the JSR 283 specification and browsing the Jackrabbit
code - good howtos had helped me, but that's the current situation.

Regards, Robert

-----Ursprüngliche Nachricht-----
Von: ttemprano [mailto:ttemprano@Toyota.com.ve]
Gesendet: Montag, 31. Januar 2011 14:09
An: users@jackrabbit.apache.org
Betreff: Re: Users and groups - Access control - Active Directory


>From what I can see the default admin user in Jackrabbit is the only user
with permissions to create new users...

I want our app to autocreate users with a set of default permissions when
they log in for the first time, however I'm still struggling with the
user/group creation/permission etc...

I find the lack of howtos and best practices info is really frustrating. I
feel like I'm about to throw in the towel...




-- 
View this message in context: http://jackrabbit.510166.n4.nabble.com/Users-and-groups-Access-control-Active-Directory-tp3238339p3248684.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

**************************************************************************************
La informacion contenida en este mail es de caracter confidencial o para uso exclusivo
del Grupo TOYOTA DE VENEZUELA en sus procesos y actividades de negocio. Los puntos de 
vista u  opiniones  presentes  en  el mismo  son  responsabilidad  del  remitente y no 
representan una posicion formal del grupo TOYOTA DE VENEZUELA (TOYOTA DE VENEZUELA, C.A.
o TOYOTA INDUSTRIAL DE VENEZUELA, C.A.). Si  UD. no  es  el destinatario o  recibio  esta

informacion por error, agradecemos destruirla de inmediato y notificar al remitente por
esta misma via, debido a que su copia, distribucion o uso esta reservado solo para
personas autorizadas.
***************************************************************************************
The information contained in this mail is strictly confidential or for the exclusive use
by TOYOTA DE VENEZUELA Group in its process and business activities. The points of view
or  present  opinions  contained  in the mail, are the senders responsibility and  dont
represent a formal opinion of TOYOTA DE VENEZUELA Group (TOYOTA  DE  VENEZUELA, C.A. or
TOYOTA INDUSTRIAL DE VENEZUELA, C.A.) If you are not the destined user or received this
information by mistake, we appreciate if you destroy  it  inmediately  and  notify  the
sender  by this same way, because its copying, distributing and use is allowed only for 
authorized people.


Mime
View raw message