jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Jbanov <pavel.jba...@gmail.com>
Subject Re: Obtaining Item or Session within AccessManager
Date Wed, 12 Jul 2006 15:00:09 GMT
Jerry Lacy wrote:
> Hello,
>  
> Is there any way to gain access to an Item given the ItemId from within the
> AccessManager checkPermission() or isGranted() methods?  Our current design
> calls for us to carry access control information as Properties of individual
> Items.  Unless I am missing something, I don't see any way to get to an Item
> using the AMContext (FileSystem or HeirarchyManager) or any way to get the
> current Session.  
>
> This makes me wonder if the approach of using Item Properties somehow
> flawed.  Is there a better approach?
>  
> Thanks in advance,
>
> Jerry Lacy
>   

I've been asking that question not too long ago on the dev list...

Torgeir Veimo wrote:

> Pavel Jbanov wrote:
>> Hi,
>>
>> I've just started with Jackrabbit and currently trying to get some 
>> security
>> going.
>> I'm trying to implement my own AccessManager. I took 
>> SimpleAccessManager as
>> a base and following the @todo comments. I'm also going to implement (or
>> hopefully find) a JAAS LoginModule to work with LDAP. The way I was 
>> planning
>> to check access to certain Node types is store a set of groups (that 
>> have
>> access to that Node) as properties in those nodes and then compare those
>> sets with the set of Principals (of Group class).
>>
>> First of all: does this approach make sense? Is there another/better
>> approach or built in support for basic role/group based access 
>> management?
>> Any examples, tutorials?
>>
>> Is it possible to get access to current Session from within 
>> AccessManager?
>> Because I need it in order to get the list of groups from the current
>> Node...
>
> It's doable. Something along the lines of
>
> public boolean isGranted(ItemId id, int permissions)
> throws ItemNotFoundException, RepositoryException {
>     if (super.isGranted(id, permissions)) {
>
>         NamespaceResolver nsResolver = 
> ((HierarchyManagerImpl)context.getHierarchyManager()).getNamespaceResolver(); 
>
>         String path = null;
>         try {
>             path = 
> context.getHierarchyManager().getPath(id).toJCRPath(nsResolver);
>         } catch (NoPrefixDeclaredException npde) {
>             log.error("unable to get JCR path: ", npde);
>             return false;
>         }
>         [...]
>         if (systemSession == null) {
>             synchronized (this) {
>                 try {
>
>                     // obtain reference to repository to obtain a 
> session instance
>                     InitialContext context = new InitialContext();
>                     Context environment = (Context) 
> context.lookup("java:comp/env");
>                     Repository repository = (Repository) 
> environment.lookup("jcr/repository");
>         // replace with whatever method you use to retrieve your 
> repository
>        
>                     systemSession = repository.login(new 
> com.somewhere.jaas.SystemCredentials());
>                 } catch (Exception e) {
>                     log.error("unable to obtain a system session; ", e);
>                     systemSession = null;
>                     return false;
>                 }
>             }
>         }
>
>         // use systemSession to retrieve ACL nodes/properties
>     }
> }
>
>
> However, the general consensus on this list seems to be that it's 
> better to implement it using a separate process that keeps track of 
> mapping between nodeIds to ACLs for those nodes.
>
> The process might very well implement this by reading repository 
> content looking for ACL entries / properties, and storing these in a 
> cache. It would register itself as an event listener on the 
> repository, and update its caches on writes to the repository.
>
// END OF QUOTED MESSAGE

But I've started having serious doubts about this approach... First of 
all: what is the point of implementing this one little standard method 
(checkPermission())  if the whole ACL storing/managing is your app 
specific anyways. You're going to add your application specific logic in 
Jackrabbit implementation. Imagine switching JCR implementations in the 
future, or Jackrabbit major architecture change...

I think it's more flexible to implement the whole thing from scratch 
based on standard JCR API.

What do you think?

Pavel


Mime
View raw message