[JBoss JIRA] Created: (JBAS-7493) StatefulSessionUnitTestCase.testBadUserTx incorrect
by Jonathan Halliday (JIRA)
StatefulSessionUnitTestCase.testBadUserTx incorrect
---------------------------------------------------
Key: JBAS-7493
URL: https://jira.jboss.org/jira/browse/JBAS-7493
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Test Suite
Affects Versions: JBossAS-6.0.0.M1
Reporter: Jonathan Halliday
Fix For: JBossAS-6.0.0.M2
org.jboss.test.cts.test.StatefulSessionUnitTestCase.testBadUserTx incorrectly uses JMX lookup of tx statistics to verify the outcome. There are two issues with this approach
1) The exposure of tx statistics is not part of the tx integration API, it's an implementation detail of the tx manager, so it should not be relied upon. Perhaps a Synchronization instead?
2) Even if it is decided to continue with this close coupling of the test suite to a component implementation, the test does not enable statistics gathering. Since this is off by default for performance reasons, the tx counter will always be 0. This may cause the test to pass in cases where it should not.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBID-233) NPE on missing SAML token when calling a saml-secured WS
by Martin Vecera (JIRA)
NPE on missing SAML token when calling a saml-secured WS
--------------------------------------------------------
Key: JBID-233
URL: https://jira.jboss.org/jira/browse/JBID-233
Project: JBoss Identity
Issue Type: Bug
Components: Identity-Federation
Affects Versions: IDFED-1.0.0.GA
Environment: SOA-P 5.0 ER6, ESB 4.7
Reporter: Martin Vecera
Assignee: Anil Saldhana
Attachments: security_saml_token.tar.bz2
When there is a web service secured using handler chain and org.picketlink.identity.federation.core.wstrust.handlers.STSSaml20Handler and the token (<Assertion ... />) is missing a NPE is thrown.
Some security exception like when the token is broken should be thrown.
The attached reproducer is a quickstart example for ESB 4.7 (should be installed in samples/quickstart directory and executed using ant deploy, ant runtest).
The exception now is:
15:39:52,332 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
java.lang.NullPointerException
at org.picketlink.identity.federation.core.wstrust.StandardRequestHandler.validate(StandardRequestHandler.java:377)
at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.handleTokenRequest(PicketLinkSTS.java:150)
at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:90)
at sun.reflect.GeneratedMethodAccessor602.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.wsf.container.jboss50.invocation.InvocationHandlerJSE.invoke(InvocationHandlerJSE.java:108)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:221)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:468)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:293)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:203)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:129)
at org.jboss.wsf.common.servlet.AbstractEndpointServlet.service(AbstractEndpointServlet.java:85)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
It should be something like:
15:35:10,652 ERROR [HandlerChainExecutor] Exception during handler processing
javax.xml.ws.WebServiceException: Could not validate security token org.jboss.ws.core.soap.SOAPElementImpl@5fa7bb73[[Assertion: null]]
at org.picketlink.identity.federation.core.wstrust.handlers.STSSecurityHandler.handleMessage(STSSecurityHandler.java:186)
at org.picketlink.identity.federation.core.wstrust.handlers.STSSecurityHandler.handleMessage(STSSecurityHandler.java:112)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:305)
at org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:142)
at org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS.callRequestHandlerChain(HandlerDelegateJAXWS.java:97)
at org.jboss.ws.core.server.ServiceEndpointInvoker.callRequestHandlerChain(ServiceEndpointInvoker.java:124)
at org.jboss.ws.core.server.ServiceEndpointInvoker.invoke(ServiceEndpointInvoker.java:199)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.processRequest(RequestHandlerImpl.java:468)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleRequest(RequestHandlerImpl.java:293)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.doPost(RequestHandlerImpl.java:203)
at org.jboss.wsf.stack.jbws.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:129)
at org.jboss.soa.esb.actions.soap.SOAPProcessor.process(SOAPProcessor.java:187)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.access$000(ActionProcessingPipeline.java:84)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline$1.run(ActionProcessingPipeline.java:1006)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline$1.run(ActionProcessingPipeline.java:1003)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:454)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:573)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:419)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBPORTAL-2040) Portal Admin very slow
by frontline frontline (JIRA)
Portal Admin very slow
----------------------
Key: JBPORTAL-2040
URL: http://jira.jboss.com/jira/browse/JBPORTAL-2040
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Core Admin
Affects Versions: 2.6.5 Final
Reporter: frontline frontline
Attachments: jamon1.gif, jamon2.gif, jamon3.gif, server.zip
We are noticing that the portal admin interface is starting to get very slow.
It apparently has to do with the amount of "portal objects" in the database.
The portal seems to create a dashboard for each user so if there are 10000 users
there are also at least that many portal objects.
In my tests I noticed that the database access takes about half of the time and
the method refresh() in PortalObjectManagerBean is also very slow.
This part is the slow part in that method (the iterator is probably the culprit, there
seems to be some "custom" implementation for it).
===
Collection portals = getSelectedObject().getChildren(PortalObject.PORTAL_MASK);
ArrayList portalList = new ArrayList(portals.size() + 1);
for (Iterator iterator = portals.iterator(); iterator.hasNext();)
{
PortalObject o = (PortalObject)iterator.next();
SelectItem item = new SelectItem(o.getName());
portalList.add(item);
}
portalList.add(new SelectItem("", "no selection"));
portalItems = (SelectItem[])portalList.toArray(new SelectItem[portalList.size()]);
===
This of course loops through all the "portal" type objects including all the user's
dashboards.
An easy optimization would be to discard the dashboard object looping when using the admin
interface because the dashboards are naturally not needed there (maybe a new type of
mask or something?).
Other problems that would be good to check is the iterator (eg. hasNext() and getting the next
object), and also why is there generated such a huge amount of SQL SELECTs (at least one per portal object).
(The following assumes that I can add attachments to this issue)
I have attached a zip file that can be extracted into a freshly installed (ie. extracted zip) portal installation
(the AS bundled version of 2.6.5) The zip contains the "server" folder so extract it at the root of the
portal installation and overwrite all files.
After the portal is started you can go to the timing report page at:
http://localhost:8080/test/jamon/jamonadmin.jsp
There you can reset the counters, access a page in the admin console, and click refresh.
After that you can sort the results by eg. the "total" column to see where time is spent.
Currently it logs the sql-statements and the refresh method in PortlaObjectManagerBean.
The timings for PortlaObjectManagerBean are split in three different parts with "*refresh"
being the time for the whole method, "*portals" the time for iterating through the portals
and "*pages" the time for looping through the pages.
Now at this stage everything is OK and the response times are good.
I have included a servlet that generates 10000 dashboards. Go to
http://localhost:8080/test/create
and wait (it takes a while, the console printsthe progress.)
Load this page only once.
After the dashboards have been created you can again test the admin console and
check the JAmon report page for results.
I have also included some screenshots from my testruns.
The first (jamon1.gif) is from a newly installed instance listing the portals in the
admin console.
The second (jamon2.gif) is the same portal list after the dashboards have been created.
The third (jamon3.gif) is after clicking "portlet instances" page. Notice how here is
generated 40000 sql selects.
Note that the included java db is quite fast at these selects. A mysql installation usually takes
about 10 seconds for 10000 selects of this type.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months
[JBoss JIRA] Created: (JBAS-4022) EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
by Erica Kane (JIRA)
EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4022
URL: http://jira.jboss.com/jira/browse/JBAS-4022
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-4.0.4.GA
Environment: Clustered
Reporter: Erica Kane
I created a security domain in the the JBoss server login-config.xml:
<application-policy name = "webappDomain">
<authentication>
<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name = "dsJndiName">java:jdbc/web</module-option>
<module-option name = "principalsQuery">select password from Users where username=?</module-option>
<module-option name = "rolesQuery">select Role, 'Roles' from Roles where username=?</module-option>
<module-option name = "unauthenticatedIdentity">guest</module-option>
</login-module>
</authentication>
</application-policy>
In jboss-web.xml, I have
<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<security-domain flushOnSessionInvalidation="true">java:/jaas/webappDomain</security-domain>
<context-root>/web</context-root>
</jboss-web>
and this works perfectly for securing web pages. However, if I put the following tag in jboss.xml:
<security-domain>java:/jaas/webappDomain</security-domain>
I find that protected EJBs default to using the "other" security domain, as shown by error messages complaining about the missing user.properties file and so on (I have left "other" on the default setting of UsersRolesLoginModule).
What DOES work is to put:
<security-domain>webappDomain</security-domain>
in jboss.xml without the java:/jaas/ prefix. However, this does not match the documentation. See
http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch8.chapter.html
example 8.8. Of course there the tag is set to java:/jaas/other, which for this bug would default to "other" anyway.
I think it is terribly confusing to have jboss.xml and jboss-web.xml using different forms for the security-domain, but even if this is necessary for some reason it should be corrected in the documentation. Other people appear to have run into this as well:
http://forum.java.sun.com/thread.jspa?threadID=773530
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 6 months