[Security & JAAS/JBoss] - JBoss 5.0.1 stubbornly ignores application-policy in login-c
by registration-form-muzz-die
Hi. I am enjoying JBoss 5.0.1 JAAS security during implementing EJB3 application server beans and client.
I cannot use EJB3 client container, since it tries to access server immediately, before any piece of my code is exceuted. So, i do InitialContext.lookup(...) instead:
try{
| SecurityClient securityClient = SecurityClientFactory.getSecurityClient();
| securityClient.setSimple("vpumpkin", "vpumpkin");
| securityClient.login();
|
| Context context = new InitialContext();
| BlankService service = context.lookup("IB-Automation/BlankServiceImpl/remote-cool.ib.service.BlankService");
| } catch(...){...}
In this code i believe, that login/passwor pair "vpumpkin"/"vpumpkin" is delivered up to JBoss server somehow by the BlankService proxy, even if i do login() in one thread, and invoke business method of EJB in another one. Right?
On the server-side i have the BlankServiceImpl bean:
@SecurityDomain(value = "IB-Automation")
| @DeclareRoles(value = {"Blank-Reader", "Blank-Writer"})
| @Stateless
| public class BlankServiceImpl implements BlankService {
|
| @Override
| @RolesAllowed({"Blank-Writer"})
| public long persist(StrictBlankEntity blank) {...}
|
| @Override
| @RolesAllowed({"Blank-Reader", "Blank-Writer"})
| public List<StrictBlankEntity> list(){...}
|
| }
I have updated the ${jboss-home}/server/default/conf/login-config.xml in the way it is described in
http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Se...
and in
http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Se...
exactly after <application-policy name="other"/> declaration: <application-policy name="IB-Automation">
| <authentication>
| <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
| <module-option name="dsJndiName">MUST_FAIL_HERE_SINCE_IT_IS_WRONG!!!</module-option>
| <module-option name="principalsQuery">
| MUST_FAIL_HERE_SINCE_IT_IS_WRONG_TOO!!!
| </module-option>
| <module-option name="rolesQuery">
| MUST_FAIL_HERE_SINCE_IT_IS_WRONG_AS_WELL!!!
| </module-option>
| </login-module>
| </authentication>
| </application-policy>
Having all these "MUST_FAIL_HERE...!!!" i expect juicy exceptions in console at the moment of retrieving datasource from JNDI or on attempts to get user info from database(anyway, with correct values it doesn't work).
I start client, and see ... exactly the result of BlankServiceImpl.list() method, like nothing prevents me to access it! Cool! :D
Well, ok... It seems, that @SecurityDomain(value = "IB-Automation") annotation is absolutely useless here. And it might work with old jboss.xml like they claim in
http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Se... ?
Let's check it!<?xml version="1.0" encoding="UTF-8"?>
| <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
|
| <jboss>
| <security-domain>java:/jaas/IB-Automation</security-domain>
| </jboss>
I deploy server-side, start client, and on attempt to invoke any method of any EJB of my app in client's console i see
EJBAccessException in thread "pool-1-thread-1": Invalid User
| org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:165)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:487)
| org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
| org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
| org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
| org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
| org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
| org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
| org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
| org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
| org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206)
| org.jboss.remoting.Client.invoke(Client.java:1708)
| org.jboss.remoting.Client.invoke(Client.java:612)
| org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
| $Proxy13.invoke(Unknown Source)
| org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase.invoke(ProxyInvocationHandlerBase.java:261)
| org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:101)
| $Proxy8.list(Unknown Source)
| cool.ib.client.Controller.listPersons(Controller.java:115)
| cool.ib.client.task.LoadPersonListTask.execute(LoadPersonListTask.java:14)
| cool.ib.client.exec.DescribedTask.run(DescribedTask.java:56)
| java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
| java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
| java.lang.Thread.run(Thread.java:619)
| org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
| $Proxy13.invoke(Unknown Source)
| org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase.invoke(ProxyInvocationHandlerBase.java:261)
| org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:101)
| $Proxy8.list(Unknown Source)
| cool.ib.client.Controller.listPersons(Controller.java:115)
| cool.ib.client.task.LoadPersonListTask.execute(LoadPersonListTask.java:14)
| cool.ib.client.exec.DescribedTask.run(DescribedTask.java:56)
| java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
| java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
| java.lang.Thread.run(Thread.java:619)
|
| WOW!!! It definitely MAY work somewhere!!! Fantastic!!! :D
Well, couple of times i enjoyed exception claiming that default users and roles .properties files, required for org.jboss.security.auth.spi.UsersRolesLoginModule cannot be found -on invoking EJB's business methods. It might be because the <application-policy name="other">...</application-policy> in the login-config.xml is invoked instead of the policy i've declared?
So i commented out application-policy name="other", restarted the server and client, but see no difference. The <application-policy name="IB-Automation"> is still being stubbornly ignored by JBoss.
What should i do to force JBoss 5.0.1 to use the declared application-policy(other than some bugfixing in the project - i am definitely neither JBoss, nor JAAS expert ;) )?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226299#4226299
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226299
17 years, 2 months
[Installation, Configuration & DEPLOYMENT] - Disable WAR classloader isolation
by altavatar
Hello,
I have 2 WARs contained in an EAR. I get the following error when I access any page in one of the webapps (note: the project uses JBoss Seam 2.1):
[VFSScanner] Error handling item 'index.page.xml' java.lang.NullPointerException: Cannot find URL from classLoader for index.page.xml, loading from org.jboss.web.tomcat.service.WebCtxLoader$ENCLoader@1687250
I'd like to see if this can be resolved by having both WARs share the same ClassLoader. I have tried using adding the following WEB-INF/jboss-web.xml file to both WARs:
<jboss-web>
| <class-loading>
| <loader-repository>
| org.jboss:archive=shared
| </loader-repository>
| </class-loading>
| </jboss-web>
But that hasnt helped. I've read that this configuration file may be ignored in AS5 as ClassLoading is delegated to Tomcat - is this correct? How can I configure JBoss AS 5 to use the same classloader for both WARs in my EAR?
Moreover, will this approach work? I imagine that it may cause filename collision or other issues?
Thanks very much.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226283#4226283
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226283
17 years, 2 months
[JBoss jBPM] - jumping to a new task node
by akriel
For various reasons within my app that is using JBPM I need to be able to abort all current tasks and jump to a different location in the process under certain circumstances (specifically if at any time the underlying data is updated). I have written a tag to do this though it isn't quite working the way I expected.
The code will create the task I specify, but it sometimes create two of them, and sometimes will also create an additional task form my startnode. I know I must be missing something but I can't see what.
Any help is greatly appreciated.
| public class RestartToNodeActionListener implements JbpmActionListener
| {
| private final ValueExpression processInstanceExpression;
| private final ValueExpression toNodeExpression;
|
| public RestartToNodeActionListener( final ValueExpression processInstance, final ValueExpression toNode )
| {
| processInstanceExpression = processInstance;
| toNodeExpression = toNode;
| }
|
| public String getName()
| {
| return "restartToNodeActionListener";
| }
|
| public void handleAction( JbpmJsfContext context, ActionEvent event )
| {
| try
| {
| final FacesContext facesContext = FacesContext.getCurrentInstance();
| final ELContext elContext = facesContext.getELContext();
| ProcessInstance processInstance = ( ProcessInstance ) processInstanceExpression.getValue( elContext );
| String toNodeName = ( String ) toNodeExpression.getValue( elContext );
|
| // get the task manager
| TaskMgmtInstance taskManager = processInstance.getTaskMgmtInstance();
|
| // get the old root token
| Token oldRoot = processInstance.getRootToken();
|
| // get the def so we can find the start node
| ProcessDefinition processDefinition = processInstance.getProcessDefinition();
|
| // get the start node to create the new root token
| Node startNode = processDefinition.getStartState();
|
| // get all tasks for the current instance
| List<TaskInstance> tasks = new ArrayList<TaskInstance>( taskManager.getTaskInstances() );
|
| int taskCount = tasks.size();
| for ( int i = 0; i < taskCount; i++ )
| {
| TaskInstance taskInstance = tasks.get( i );
|
| if ( taskInstance != null )
| {
| // remove each task instance
| taskManager.removeTaskInstance( taskInstance );
|
| // if the task is active cancel it
| if ( taskInstance.isOpen() && !taskInstance.isCancelled() )
| {
| // try to cancel the task instance
| taskInstance.cancel();
| }
| }
| }
|
| // added this because not all tasks were being canceled and was hoping it would be a catch all.
| taskManager.endAll();
|
| // get the task definition manager
| TaskMgmtDefinition taskManagerDefinition = taskManager.getTaskMgmtDefinition();
|
| // set the node we want to jump to
| Task startTask = taskManagerDefinition.getTask( toNodeName );
|
| // get the node to move the root token to
| Node startingNode = taskManagerDefinition.getProcessDefinition().getNode( toNodeName );
|
| // set the root token to point to the node
| oldRoot.setNode( startingNode );
|
| // create the new task instance
| TaskInstance newStartInstance = taskManager.createTaskInstance( startTask, oldRoot );
|
| // add in a start task
| taskManager.addTaskInstance( newStartInstance );
|
|
| context.selectOutcome("success");
| }
| catch ( Exception ex )
| {
| context.setError( "Error clearing tasks and resetting to task", ex );
| return;
| }
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226278#4226278
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4226278
17 years, 2 months