Hi Alex,
thanks for this great summary! Does it make sense to put it on the
website or on the Wiki?
-- Andreas
Alexander Klimetschek schrieb:
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
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
