You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Jerry Lacy <jl...@ssglimited.com> on 2006/07/12 16:32:31 UTC
Obtaining Item or Session within AccessManager
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
Re: Obtaining Item or Session within AccessManager
Posted by Tobias Bocanegra <to...@day.com>.
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 <pa...@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 >---
Re: Obtaining Item or Session within AccessManager
Posted by Pavel Jbanov <pa...@gmail.com>.
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