From: mholzner <do-...@jb...> - 2005-09-20 18:48:21
|
despite the danger of beating a dead horse, what is the difference between what the current code does, and the proposal of providing a fallback inside the policy? Right now JaccAuthorizationRealm.establishSubjectContext() does exactly what this argument is about. It first checks the PolicyContext for an available Subject, and only if that is not there, it falls back to try and make sense out of the provided principal (which comes from the HttpServletRequest.getCallerPrincipal()) So why not have the Policy first check the ProtectionDomain, and if none is provided, fall back to the PolicyContext and get the Subject from there, rather then throwing a SecurityException if no PD is provided. I don't see where this would introduce any more or less authorization related functionality then what the current JACC code does already.... I have to admit that I'm not an expert in this field, but I don't understand your argumentation. Feel free to ignore me if this is starting to be a silly argument, but I just don't get it so far. After all this is not critical, we can go either way in the implementation, this is only for my ego. I'd like to understand it ;) The other argument that I wanted to raise is that of custom user code that would like to use this security feature. What if a Servlet or a Portlet wants to create new permission classes and do security checks against the policy with them? Wouldn't it be better to provide a simplified API that takes care of the principal/subject determination rather then forcing that client code to get the subject from the PolicyContext (which as I understand it, would require the custom code to be configured in the J2SE policy file to be allowed to access the subject via the PolicyContext....) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3895857#3895857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3895857 |