jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <ju...@zitting.name>
Subject Re: User permissions in JCR
Date Wed, 01 Jun 2005 14:12:50 GMT

Maxim wrote:
> It looks like my previous post was missed,
> so I will try to ask my question again.

Sorry about that. I think that most of the Jackrabbit developers are 
currently heavily involved in making JSR 170 final. I'll try to answer 
the best I can.

> In Jackrabbit current implementation of access permissions
> (org.apache.jackrabbit.core.security) it is only possible to have "all
> permissions" (superuser) or "read-only" (anonymous) session.
> Is it planned to add more flexible permission system to Jackrabbit, so
> it will be possible to have different permissions for different nodes,
> for the single session.

You are right in that the current SimpleAccessManager implementation 
only supports a very coarse permission set. However, the idea is to 
extend the SimpleAccessManager to support a more fine-grained set of 
JAAS permissions. How and when this will be done is still an open 
question, you should file an enhancement request in Jira if you want to 
speed up the process.

In addition to the default JAAS access manager, it is possible to 
implement custom access control mechanisms by implementing the 
AccessManager interface. There have been a few questions about this on 
the list before, it would be nice to hear about any 
succeses/difficulties people have experienced with this approach.

> Another JCR question is not Jackrabbit specific. Consider an
> application which uses some JCR implementation and this application
> requires setting permissions for nodes on behalf of its users. As
> there is no API to set user permissions for nodes specified in JCR,
> which API should be used in such application?

Access control is in general a very complex issue, and I think that the 
API is correct in not trying to mandate a single solution. It could also 
be argued that access control is a management function just like node 
type management that also is outside the scope of JSR 170. I think that 
JSR 170 is correct in specifying the effects of access control 
violations (javax.jcr.AccessDeniedException, etc.) but not the mechanism 
for modifying or even querying access control settings.

 > If, as JCR states, permission system is left up to implementation,
 > then is such application forced to used some proprietary API to set
 > permissions? Doesn't this compromise entirely a concept of "switching
 > repository implementations" and avoiding vendor lock-in?

There are a number of applications that never need to manage access 
control settings, or handle more fine-grained access settings using 
application-level flags or ACLs.

Do you have some specific use case in mind? It would be interesting to 
discuss the "correct" way to implement such "permission-intensive" 
applications on top of JCR.


Jukka Zitting

View raw message