Scott M Stark wrote:
>
> >> Right, but this only applies to certain instances if each folder was a bean, or
> >> certain paths if there is one master doc repository bean. To take it a step
>further,
> >> you may only be able to put a document in a folder if you are an Architect and
> >> you are the owner/creator of the parent folder. In general security requirements
> >> cannot be described only in terms of roles.
> >
> >Hmm... I still don't see the problem. AFAICT you can use isCallerInRole
> >to do precisely what you outline above. What am I missing?
> >
> >/Rickard
>
> How would you do it? This is the check that I am describing and I don't
> see how to recast it as a role/principal only based check:
>
> public class ProjectRepositoryBean implements SessionBean
> {
> SessionContext ctx;
>
> public void uloadFile(String folderPath, ...)
> {
> String folderOwner = this.getAttribute("owner");
> boolean isOwner = ctx.getCallerPrincipal().getName().equals(folderOwner);
> if( ctx.isCallerInRole("Architect") == false || isOwner == false )
> throw new EJBException(new SecurityException("Insufficent privaledges"));
> }
> ...
>
> The folder owner is not a role, its a relationship to the caller's principal
>identity. I
> can't write a role mapping class that can satisfy isCallerInRole("Owner") without
> also having access to the beans state. Do you have a trick that I'm not seeing?
No, you are doing exactly what I thought you should do (although
"Architect" is hardcoded above, but that's not necessary either). And
what is the problem with the above?
> A simpler check that also moves the implementation details of the security
> check outside of the business logic class would be to issue a Java2 style
> checkPermission call:
>
> ...
> public void uloadFile(String folderPath, ...)
> {
> Permission p = new ProjectDocPermission(folderPath, "upload");
> try
> {
> AccessController.checkPermission(p);
> }
> catch(SecurityException e)
> {
> throw new EJBException(e);
> }
>
> }
> ...
>
> What I really want is to move even this check to a security proxy layer so that
> I can change even the permissions that are required independent of the business
> logic.
Sure, that's what I'd recommend too. Go right ahead I say: generate a
subclass of your session which contain this check. Is there a problem
with doing this?
If you want to go JBoss specific you could do this security as an
interceptor.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
