Ben Alex wrote:
It beats me what business a content repository has authenticating users in the first place. Surely the container the repository is running in would do that. Especially with more complex authentication mechanisms existing out there like X509, Digest and Single Sign On. The repository should just be passed an Object that represents the authenticated user, courtesy of the container. The repository then associates that Object with the content repository session and can enforce ACLs.
they've essentially done that by allowing you to pass null credentials when logging into the repository. when you do so, the spec assumes that an authenticated Subject is available via the current AccessControlContext.
here's what i had to do to bypass JAAS (where securityContext is an object that retrieves the Authentication from the SecureContext and packages it up in a javax.security.auth.Subject):
PrivilegedAction action = new PrivilegedAction() {
public Object run() {
try {
return repository.login(workspaceName);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
};
Session rs = (Session)
Subject.doAs(securityContext.getSubject(), action);Thanks for that Brian. It looks good.
my pleasure. i didn't see that there were any other JAAS classes, but i probably didn't look hard enough :)
------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
