jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject Re: JSR 283 - Public Review - Content Repository for JavaTM Technology API Version 2.0
Date Tue, 17 Jul 2007 15:50:50 GMT
Hi Tor,

thanks for your feedback.

Please feel free to also send it to jsr-283-comments@jcp.org to make sure that
it is considered by the expert group.

> > (2) Access Control Management to go beyond the introspection that is
> > already specified
> > in JCR v1.0
> It seems that access control in JCR 2.0 is limited to declarative
> security?
It was not our intention to limit access control models at all.

JCR v2.0 proposes a default declarative access control mechanism
as well as a an abstract policy based one.

Obviously every repository is free to offer other means of access control
beyond that, and in the case of Jackrabbit i think it is safe to say that
access control will always remain "pluggable".

> I think this is a very bad restriction. Declarative security was
> never sufficient enough for EJBs, and is surely not sufficient for
> all types of applications which might be built on top of a JCR
> repository, and is very often much more verbatim than implied or
> programmatic security.
I think it is a very good observation that we probably cannot come up
with an access control model in JCR that fits all needs, that's
why we never wanted to be restrictive or exclude any particular
way of dealing with access control.

I guess we looked at the access control management spec as a default
standard way how access control can be dealt with in a repository
ootb. By no means as the only way to deal with access control.

Regarding the EJB comment:
I would also like to mention that access control management tends
to work much more intuitively in systems that support the concept of
hierarchy (like for example a filesystem or a content repository) than in
systems that don't (like for example rdbms in general).

> What I'd like to see would be some means of getting access to Nodes
> in a read-only "before" session and an "after" session in a security
> manager. This would allow implementing a wide range of different
> security managers depending on the application at hand.
> I guess there are technical challenges with implementing such session
> access, but it could be an optional feature, and the suggested next
> generation persistence architecture would probably easily support it.
I am not sure I understand your suggestion correctly.
Do you think you could explain it a little bit more in detail, maybe with
a specific example?

Generally, I think when it comes to very abstract concepts of
authorization I think JAAS provides you with everything
necessary. It certainly was never our intention to either re-specify JAAS
or exclude JAAS based architectures.

Please let me know if I misinterpreted your comments.

Thanks & regards,

View raw message