Hi Tor, thanks for your feedback.
Please feel free to also send it to [EMAIL PROTECTED] 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, david
