[Design of Security on JBoss] - Re: Why do we need a security context to access a local ejb?
by adrian@jboss.org
You don't need to run the testsuite, just copy that jar into deploy.
This patch fixes it:
| Index: src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java
| ===================================================================
| --- src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java (revision 72017)
| +++ src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java (working copy)
| @@ -532,18 +532,16 @@
| {
| SecurityContext sc = getSecurityContext();
| if(sc == null)
| - throw new IllegalStateException("No security context for getPrincipal");
| + return null;
| return sc.getUtil().getUserPrincipal();
| - //return SecurityAssociation.getPrincipal();
| }
|
| public Object getCredential()
| {
| SecurityContext sc = getSecurityContext();
| if(sc == null)
| - throw new IllegalStateException("No security context for getCredential");
| + return null;
| return sc.getUtil().getCredential();
| - //return SecurityAssociation.getCredential();
| }
|
| public SecurityContext getSecurityContext()
| @@ -561,9 +559,8 @@
| {
| SecurityContext sc = getSecurityContext();
| if(sc == null)
| - throw new IllegalStateException("No security context for getPrincipal");
| + return null;
| return sc.getUtil().getUserPrincipal();
| - //return SecurityAssociation.getPrincipal();
| }
| };
|
| @@ -573,9 +570,8 @@
| {
| SecurityContext sc = getSecurityContext();
| if(sc == null)
| - throw new IllegalStateException("No security context for getCredential");
| + return null;
| return sc.getUtil().getCredential();
| - //return SecurityAssociation.getCredential();
| }
| };
|
I don't think this is full fix, since it should be roughly the same logic as
org.jboss.proxy.SecurityInterceptor.
SecurityInterceptor is used when a remote ejb proxy is operating in local optimization
mode, while BaseLocalProxyFactory is used for purely local proxies.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143527#4143527
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143527
17 years, 12 months
[Design of Security on JBoss] - Why do we need a security context to access a local ejb?
by adrian@jboss.org
With the old SecurityAssociation we didn't need to login to access a local EJB.
If the ejb was secured, it just failed because of the null principal,
otherwise the request was allowed.
| 21:00:26,618 ERROR [AbstractKernelController] Error installing to Start: name=jboss.test:service=CtsCmpServiceV1 state=Create mode=Manual requiredState=Installed
| java.lang.IllegalStateException: No security context for getPrincipal
| at org.jboss.ejb.plugins.local.BaseLocalProxyFactory$SecurityActions$1.getPrincipal(BaseLocalProxyFactory.java:535)
| at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:354)
| at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
| at $Proxy87.create(Unknown Source)
| at org.jboss.test.cts.service.CtsCmpService.startService(CtsCmpService.java:53)
|
Try deploying testsuite/output/lib/cts-v1cmp-sar.ear in JBoss5
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143518#4143518
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143518
17 years, 12 months
[Design of POJO Server] - JBoss5 is better than JBoss4.2 :-)
by adrian@jboss.org
I've been trying to figure out why some of the tests fail in JBoss5
but work in JBoss4.2, even though the code and config looks the same.
No matter how hard I looked at the code I couldn't see the difference. :-)
The answer is actually that JBoss5 spots the error during deployment
while 4.2 doesn't.
e.g. I couldn't figure out why this config was working in JBoss-4.2 but not in JBoss5
| <server>
| <mbean code="org.jboss.test.cts.service.CtsCmpService"
| name="jboss.test:service=CtsCmpServiceV1">
| <attribute name="HomeJndiName">v1/local/CtsCmp2Bean</attribute>
| <depends>jboss.j2ee:service=EJB,jndiName=v1/CtsCmp2Bean</depends>
| </mbean>
| </server>
|
The actual ejb was called v1/local/CtsCmp2Bean.
I thought there might be something we missed in the reworking of the metadata
that introduced a backwards compability issue.
In fact, the config is wrong in JBoss-4.2, but the deployer doesn't spot it.
If I use the JMX console in 4.2 to do MainDeployer.checkIncompleteDeployments()
I get the following error:
| Incomplete Deployment listing:
|
| --- MBeans waiting for other MBeans ---
| ObjectName: jboss.test:service=CtsCmpServiceV1
| State: CONFIGURED
| I Depend On:
| jboss.j2ee:service=EJB,jndiName=v1/CtsCmp2Bean
|
| --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
| ObjectName: jboss.j2ee:service=EJB,jndiName=v1/CtsCmp2Bean
| State: NOTYETINSTALLED
| Depends On Me:
| jboss.test:service=CtsCmpServiceV1
|
|
| org.jboss.deployment.MainDeployer.checkIncompleteDeployments(MainDeployer.java:1385)
|
which is the same as what I get in JBoss5 but without having to use the jmx console
to find the problem. ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4143510#4143510
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4143510
17 years, 12 months