jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: Obtaining Item or Session within AccessManager
Date Thu, 13 Jul 2006 07:54:16 GMT
the access manager is not yet that pluggable, i.e. it does not give
you alot of access to the repository. i will open a new jira bug that
covers this issue.

regards, toby

On 7/12/06, Pavel Jbanov <pavel.jbanov@gmail.com> wrote:
> 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
>
>


-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

Mime
View raw message