-
1. Re: JACC on the fly method permission changes not reflecting
jaikiran Aug 8, 2006 8:19 AM (in response to tpnaidu79)The login credentials are cached. Have a look at:
http://www.jboss.org/wiki/Wiki.jsp?page=CachingLoginCredentials -
2. Re: JACC on the fly method permission changes not reflecting
jaikiran Aug 8, 2006 11:07 AM (in response to tpnaidu79)However, when I try to change the role based ejb3 method permission on the fly
Apologies. Hadnt read your question correctly. The link that i mentioned in my previous reply might not be a solution. -
3. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 9, 2006 2:38 AM (in response to tpnaidu79)Disabling the cache of login credentials affects the credentials of the subject / principals.. However I am changing the method permission of an ejb session bean. The credentials are used to act on the ejb method... I am changing the ejb side permissions not the subject side credentials,... hence in this case i dont think flushing the login credentials cache makes a difference...
-
4. Re: JACC on the fly method permission changes not reflecting
j2ee_junkie Aug 9, 2006 8:44 AM (in response to tpnaidu79)P,
Can you show us how you are attempting...
I try to change the role based ejb3 method permission on the fly
thanks cgriffith -
5. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 9, 2006 9:41 AM (in response to tpnaidu79)I have a method in a session bean called JobServiceBean. The method is as follows:
@RolesAllowed("Recruiter")
public void outputJunk() {
System.out.println("#######");
}
Now after authentication using JAAS, I am writing code to change the @RolesAllowed from "Recruiter" to "Hiring Manager" as follows:
EJBMethodPermission ejbmp = new EJBMethodPermission("JobServiceBean","");
PolicyConfigurationFactory pcf = PolicyConfigurationFactory.getPolicyConfigurationFactory();
PolicyConfiguration pc = pcf.getPolicyConfiguration("kr.jar", false);
pc.removeRole("Recruiter");
pc.addToRole("Hiring Manager", ejbmp);
pc.commit();
IMHO once commit is called, the @RolesAllowed is now changed from "Recruiter" to "Hiring Manager" so when a user with the role "Hiring Manager" tries to run outputJunk() method in JobServiceBean he should be able to do it. But I am getting an Exception as follows:
19:10:52,711 ERROR [RoleBasedAuthorizationInterceptor] Insufficient permissions, principal=admin, requiredRoles=[Recruiter], principalRoles=[Hiring Manager]
19:10:59,305 ERROR [STDERR] javax.ejb.EJBAccessException: Authorization failure
19:10:59,305 ERROR [STDERR] at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:104)
19:10:59,305 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
19:10:59,305 ERROR [STDERR] at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
19:10:59,305 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
19:10:59,321 ERROR [STDERR] at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
19:10:59,321 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
19:10:59,321 ERROR [STDERR] at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
19:10:59,321 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
19:10:59,321 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:181)
19:10:59,321 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
19:10:59,321 ERROR [STDERR] at $Proxy90.outputJunk(Unknown Source)
19:10:59,321 ERROR [STDERR] at com.kenexa.kr.web.LoginControllerBean.login(LoginControllerBean.java:118)
19:10:59,321 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
19:10:59,321 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
19:10:59,321 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
19:10:59,321 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
19:10:59,336 ERROR [STDERR] at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:129)
19:10:59,336 ERROR [STDERR] at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:63)
19:10:59,336 ERROR [STDERR] at oracle.adf.view.faces.component.UIXCommand.broadcast(UIXCommand.java:211)
19:10:59,336 ERROR [STDERR] at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:90)
19:10:59,336 ERROR [STDERR] at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:164)
19:10:59,336 ERROR [STDERR] at org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.java:316)
19:10:59,336 ERROR [STDERR] at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)
19:10:59,336 ERROR [STDERR] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:106)
19:10:59,336 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
19:10:59,336 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
19:10:59,336 ERROR [STDERR] at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._invokeDoFilter(AdfFacesFilterImpl.java:356)
19:10:59,352 ERROR [STDERR] at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl._doFilterImpl(AdfFacesFilterImpl.java:325)
19:10:59,352 ERROR [STDERR] at oracle.adfinternal.view.faces.webapp.AdfFacesFilterImpl.doFilter(AdfFacesFilterImpl.java:190)
19:10:59,352 ERROR [STDERR] at oracle.adf.view.faces.webapp.AdfFacesFilter.doFilter(AdfFacesFilter.java:87)
19:10:59,352 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
19:10:59,352 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
19:10:59,352 ERROR [STDERR] at org.apache.myfaces.webapp.Filter.doFilter(Filter.java:202)
19:10:59,352 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
19:10:59,352 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
19:10:59,352 ERROR [STDERR] at org.apache.myfaces.component.html.util.ExtensionsFilter.doFilter(ExtensionsFilter.java:122)
19:10:59,352 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
19:10:59,368 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
19:10:59,368 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
19:10:59,368 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
19:10:59,368 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
19:10:59,383 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
19:10:59,383 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
19:10:59,383 ERROR [STDERR] at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
19:10:59,383 ERROR [STDERR] at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
19:10:59,383 ERROR [STDERR] at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
19:10:59,383 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)
19:10:59,399 ERROR [STDERR] Caused by: java.lang.SecurityException: Insufficient permissions, principal=admin, requiredRoles=[Recruiter], principalRoles=[Hiring Manager]
19:10:59,399 ERROR [STDERR] at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:150)
19:10:59,399 ERROR [STDERR] at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:100)
19:10:59,399 ERROR [STDERR] ... 53 more
Am i doing anything wrong?? or am I missing something??
-P -
6. Re: JACC on the fly method permission changes not reflecting
j2ee_junkie Aug 9, 2006 10:46 AM (in response to tpnaidu79)P,
What does JBoss use as contextID? I am wondering if you need to use "ear-name/bean-jar-name".
cgriffith -
7. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 9, 2006 11:56 AM (in response to tpnaidu79)My application has an ear called kr.ear. This ear has a kr.jar, which contains all the ejbs and a kr.war which contains the jsps etc.
The contextID i am using in this case is "kr.jar", since my ejbs are in the kr.jar archive.
-P -
8. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 10, 2006 1:58 AM (in response to tpnaidu79)According to the JACC spec When I call commit() on a PolicyConfiguration object , the PolicyConfiguration for that contextId is set inService (i.e; made active). I am able to debug and inspect the object state before commit() is called and after it is called. The PolicyConfiguration is reflecting the changes made by me on the fly. However, the behaviour of the container is as per the previous rules given as system startup. I tried to go through the JBossAS source code to figure out what the container was doing on commit(). JBossAS has a class called JBossPolicyConfiguration which is the implementation of PolicyConfiguration interface as defined by the JACC spec. The commit() method in JBossPolicyConfiguration in turn calls the commit() method of a DelegatingPolicy object which in turn calls the commit() method of a ContextPolicy object. The commit() method of a contextPolicy object is an empty method, it has no refresh or anything... in this case how does the container become aware of on the fly ejb method permission changes? The code of what I was trying to explain above is as follows:
JBossPolicyConfiguration code:
public void commit()
throws PolicyContextException
{
if( trace )
log.trace("commit");
validateState("commit");
policy.commit(contextID); // policy is a DelegatingPolicy object
}
DelegatingPolicy code:
public void commit(String contextID)
throws PolicyContextException
{
ContextPolicy policy = getContextPolicy(contextID);
openPolicies.remove(contextID);
activePolicies.put(contextID, policy);
policy.commit();
}
ContextPolicy code:
void commit()
throws PolicyContextException
{
}
I guess I am missing something here can anyone please help me.
Thank you,
-P -
9. Re: JACC on the fly method permission changes not reflecting
j2ee_junkie Aug 11, 2006 10:15 AM (in response to tpnaidu79)I had started to digest the JACC spec and how JBoss implements it a few months back, but have not looked at it recently. So this is pure speculation on what I think I know.
The point I was trying to make is that you have been modifying the PolicyContext specified by contextID "kr.jar". That does not mean that it is the same contextID set by container for your component. To be more specific, JBoss creates and configures the Policy at deployment time under a specific contextID. I am not sure what that is. Then your code comes along and tries to modify that context, but are you actually configuring the same context.
cgriffith -
10. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 17, 2006 1:52 AM (in response to tpnaidu79)I think the problem is that JACC is not being used by Jboss by default. When I try to debug and see the code flow it goes to RoleBasedAuthorizationInterceptor and not JaccAuthorizationInterceptor. The Insufficient permission exception is thrown by the RoleBasedAuthorizationInterceptor. How do I register the JaccAuthorizationInterceptor to handle my authorization needs?
-P. -
11. Re: JACC on the fly method permission changes not reflecting
anil.saldhana Aug 17, 2006 10:57 AM (in response to tpnaidu79)What is the container configuration being applied for your EJB from standardjboss.xml?
-
12. Re: JACC on the fly method permission changes not reflecting
anil.saldhana Aug 17, 2006 10:58 AM (in response to tpnaidu79)Replace SecurityInterceptor with a combo of "JaasAuthenticationInterceptor" and "JaccAuthorizationInterceptor" with the same package as before.
-
13. Re: JACC on the fly method permission changes not reflecting
tpnaidu79 Aug 18, 2006 3:06 AM (in response to tpnaidu79)Thank you Anil,
I got it to work... but I have to give @AspectDomain("JACC Stateless Bean") in the ejb for every such ejb if i want its security to be JACC managed. Can i set aspect domain throught the system like I do for security-domain in jboss.xml. I tried it but it doesnt seem to be supported. Is there any other way to set Aspect Domain through jboss.xml??
-P