- SimpleSecurityManager (specified in repository.xml)<=> SecurityManager
specified by the *-Djava.security.manager *. Not relevant so far for
authentication, isn't it?
yes, it might be relevant depending on the rest of the configuration
as the simplesecuritymanager defines a default entry in the principal
provider registry. that one takes effect if you don't specify one with
your login module configuration.
- security.xml<=> *-Djava.security.policy==/path/to/sampleazn.policy* . The
policy is specified in security.xml file. By the way, i did not find any
link to security.xml syntax nor samples are provided with Jackrabbit
distributions, any useful link?
afaik this has nothing to to with jackrabbit's default access
control mechanisms which secures on the jcr items present in the
repository and the operations executed on them. this rather originates
from java security functionality which operates on java code itself.
- SimpleLoginModule (specified in repository.xml and *always return true*,
regardless what parameters it gets)<=> *
this was the original jackrabbit setup before we had the complete
security functionality which was added for JCR 2.0. that's not
meant to be used in a productive environment.
-Djava.security.auth.login.config==/path/to/sample_jaas.config* pointing to
SampleLoginModule (a custom class provided in the JAAS tutorial which
performs a very simple authentication which checks if the given username and
password correspond to fixed strings).
you will either have JAAS or the 'local' loginmodule configuration
present in the repository.xml. if both a present the local config
takes precedence (if i remember correctly).
- AccessManager (specified in repository.xml): not relevant so far for
authentication, isn't it?
correct.
So, having the sources from Jackrabbit downloaded and checking what happens
using Eclipse debugger i would say that i must implement my own
"SimpleLoginModule" with my own logic to determine whether authentication
succeeds or not (looking for username and password in a database, for
example).
right... you may also take a look at defaultloginmodule which is
slightly more sophisticated and better suited for real-world usage.
instead of looking for users in the database it uses jackrabbit
user management API to access/validate users.
Then specify it in repository.xml file for Jackrabbit to use it.
Would my guess be correct? Would be the procedure i described the most
convenient way to catch every authentication try (when getting the
repository via webdav, rmi, jndi or accessing the contents through HTTP)
i doesn't matter how you access the repository. the authentication
mechanisms interally used by the repository should not be affected
by the way to access the repo... all of the ways you mention will
end in call to Repository.login(Credentials creds, String workspace)/
hope that helps
angela
