On Tue, Mar 10, 2009 at 1:03 PM, Andreas Hartmann <andr...@apache.org> wrote: > actually I didn't intend to do any beta-testing (yet), but somehow I got the > impression that OpenID is the only supported way for authentication ATM. But > I just noticed that I can simply disable anonymous access in the > configuration console to enable the built-in authentication …
In general the idea with JCR is that the repository handles authentication and authorization, because it makes things simple and content-oriented (and no need to put security access checks across the application code). That's why Sling uses a single JCR session for each request with a certain logged-in user. The credentials for this session are fetched using an o.a.s.engine.auth.AuthenticationHandler - currently there is a handler using HTTP basic auth (bundles/extensions/httpauth) and the OpenID handler. You can quite easily write your own, for using a cookie-based mechanism or to do SSO stuff. Those credentials provided by the handler are then used by Sling for the JCR Repository.login() method that will return the session. How the authentication is done inside the JCR repository is up to the implementation (for JCR 1.0). Previous Jackrabbit versions (up to 1.4.x I think) only provided a simple login module out of the box that provided anonymous, admin and normal users (whereas only for the special admin user a password could be set in the repository.xml config, ie. you couldn't really call it security ;-)). The recent Jackrabbit releases introduced proper user management, mainly because JCR 2.0 will define more in this respect (and Jackrabbit is already working towards that new version of the spec). For this, users (incl. their passwords and other preferences) are stored inside the repository itself, typically in a separate workspace to ensure a strict separation of "system" stuff and application content (although that is freely configurable I think). Now if you are logged in with the session in the request and some servlets or scripts are trying to read and write from the repository, the authorization comes into play. Things that you cannot read are simply not visible through the JCR API (ie. you get a "404" and not a "403" when speaking in HTTP status codes ;-)). If write access is denied, you get that AccessDeniedException on save(). The authorization is now also done inside the repository and for previous Jackrabbit versions there effectively was no built-in authorization. The 1.5 release contains the aforementioned implementation based on what the JCR 2.0 spec is saying (so far, it's not final yet ;-)). This stores the ACLs in the repository as well, right at the nodes to which these belong. There is also an API to manually set those ACLs (I think one is free again to store those ACLs whereever you want, if you'd like to change the default authorization manager in Jackrabbit). The documentation on that is a bit sparse yet, reading the code and searching the Jackrabbit mailing list archives is the best you can do at the moment :-) <spam> You might have seen the commercial CRX repository built on top of Jackrabbit, which provides a full authentication and authorization implementation for some time now and has a GUI to manage the users and ACLs (and it bundles Sling). </spam> Hope that helps as an overview, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
