Hi Brian, Excellent information! It is extremely helpful to hear how you implemented security for a similar situation, and also let's me know that I'm at least not missing anything huge. :)
Ryan "Brian Moseley" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Ryan Dewell wrote: > >> Thanks for the reply. What I'm gathering from your post and re-reading >> the spec sections on workspaces is that the actual use of workspaces is >> more of an exotic case that is probably not applicable or desireable in >> my situation. What it sounds like I want to do is use one workspace and >> implement my own security layer over the top of that to protect access to >> resources. For example, to keep x:jane out of x:bob's stuff. So, when >> either x:jane or x:bob logs in, they get the same workspaces with the >> same root, but their access to resources would be restricted. >> >> From a jackrabbit standpoint, it looks like that means implementing my >> own AccessManager. Does anyone know if there is a good reason that the >> AMContext has no access to the current Session or Repository? If I want >> to implement a security mechanism where the permission data is actually >> stored in the repository as well, it would be handy to have access to the >> Repository or Session from AccessManager. Although, I guess there's no >> reason I couldn't get the same Repository instance from JNDI in my own >> AccessManager implementation. Thinking out loud at this point... > > fwiw - what you're talking about is exactly what i've done. i create user > home directories as nt:folder nodes just below the root node. > > i have a custom AccessManager that implements rudimentary home directory > owner permissions. in my app, that means the principal's name is the same > as the display name of the home directory node. > > i ran into a situation as well where the AMContext didn't give me enough > info. jackrabbit checks permissions on the version storage node > (/jcr:system/jcr:versionStorage) when creating a node. AMContext doesn't > have enough info for me to look up the node that's related to the version > history being created so that i can do owner permission checks on it. not > the same as your situation, but also shows that we're probably looking to > do things with AccessManager that folks didn't originally envision :) > > fwiw, i've implemented my security layer with Acegi Security, so my > AccessManager doesn't care where the permission info is stored. it just > checks the Subject for a principal that has all the security info already > loaded (my app does that in a servlet filter prior to accessing the > repository). >
