[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on JBREM-1317:
----------------------------------
I've been thinking about this issue, and I'm not convinced that anything needs to be done.
1. If there's a failure of a control connection, then there's always the possibility that a new one will be created, assuming that pinging is enabled for control connections. BisocketClientInvoker.createSocket() takes that possibility into account, checking for a new control connection each time around the loop.
2. If there's a more global problem, e.g., a network failure or a client getting shut down, then the Lease will time out and notify JBossMessaging, which will shut down the connection.
Doug, what do you think?
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (SECURITY-728) WebJASPIOptionalAuthenticator does not actually authenticate
by arjan tijms (JIRA)
arjan tijms created SECURITY-728:
------------------------------------
Summary: WebJASPIOptionalAuthenticator does not actually authenticate
Key: SECURITY-728
URL: https://issues.jboss.org/browse/SECURITY-728
Project: PicketBox
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: PIcketBox_4_0_15.Final
Reporter: arjan tijms
Assignee: Anil Saldhana
According to the JASPIC specification, a SAM should be invoked for unprotected resources as well as protected resources. Invoking the SAM for unprotected resources is required for pre-emptive authentication.
This is detailed in section 3.8 of the JSR 196 (JASPIC) specification and is explicitly acknowledged by the spec lead at http://java.net/jira/browse/SERVLET_SPEC-21
However, the documented {{WebJASPIAuthenticator}} valve is not invoked for unprotected resources. There is an undocumented valve, {{WebJASPIOptionalAuthenticator}}, which can be used, but this one does not actually authenticate.
See the following fragment:
{code}
boolean isValid = sam.isValid(messageInfo, new Subject(), messageLayer, appContext, cbh);
if (isValid) {
WebLogger.WEB_SECURITY_LOGGER.debugf("JASPI validation for unprotected request context %s succeeded", request.getServletPath());
sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
}
{code}
As can be seen, the callbackhandler ({{cbh}}) is *not* processed.
Additionally, the javadoc comments for {{WebJASPIOptionalAuthenticator}} says calling unprotected resources is optional, but I don't think this is the case:
{code}
/**
* <p>
* This class implements a JASPI authenticator for unprotected resources. In the JASPI Servlet profile, authentication
* for unprotected resources is optional but it is still allowed. When performed, the JASPI authentication modules must
* grant access to the unprotected resources irrespective of the caller, which may be anonymous (i.e, no security info
* supplied).
* </p>
*
* @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
*/
@SuppressWarnings("unused")
public class WebJASPIOptionalAuthenticator extends ValveBase {
{code}
{{WebJASPIOptionalAuthenticator}} should probably contain the following code in the {{isValid}} if statement:
{code}
PasswordValidationCallback pvc = cbh.getPasswordValidationCallback();
CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback();
// get the client principal from the callback.
Principal clientPrincipal = cpc.getPrincipal();
if (clientPrincipal == null) {
clientPrincipal = new SimplePrincipal(cpc.getName());
}
// if the client principal is not a jboss generic principal, we need to build one before registering.
if (!(clientPrincipal instanceof JBossGenericPrincipal))
clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal);
this.register(request, response, clientPrincipal, authMethod, pvc.getUsername(),
new String(pvc.getPassword()));
{code}
(code taken from {{WebJASPIAuthenticator}}).
Perhaps it's better if the two valves are merged?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (SECURITY-727) secureResponse with JASPIC called before service invocation instead of after
by arjan tijms (JIRA)
arjan tijms created SECURITY-727:
------------------------------------
Summary: secureResponse with JASPIC called before service invocation instead of after
Key: SECURITY-727
URL: https://issues.jboss.org/browse/SECURITY-727
Project: PicketBox
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: PIcketBox_4_0_15.Final
Reporter: arjan tijms
Assignee: Anil Saldhana
{{WebJASPIAuthenticator}} in JBoss AS 7.1.1 and JBoss EAP 6.0.1 calls _secureResponse_ right after _validateRequest_ on a SAM has been called. The only intermediate code is registering the result of the callback handler with the container. The service invocation (e.g. calling a Servlet) is done afterwards, ie after the call to _secureResponse_.
See the following fragment in {{WebJASPIAuthenticator}}:
{code}
if (sam != null) {
result = sam.isValid(messageInfo, clientSubject, messageLayer, appContext, cbh);
}
// the authentication process has been a success. We need to register the principal, username, password and roles
// with the container
if (result) {
PasswordValidationCallback pvc = cbh.getPasswordValidationCallback();
CallerPrincipalCallback cpc = cbh.getCallerPrincipalCallback();
// get the client principal from the callback.
Principal clientPrincipal = cpc.getPrincipal();
if (clientPrincipal == null) {
clientPrincipal = new SimplePrincipal(cpc.getName());
}
// if the client principal is not a jboss generic principal, we need to build one before registering.
if (!(clientPrincipal instanceof JBossGenericPrincipal))
clientPrincipal = this.buildJBossPrincipal(clientSubject, clientPrincipal);
this.register(request, response, clientPrincipal, authMethod, pvc.getUsername(),
new String(pvc.getPassword()));
if (this.secureResponse)
sam.secureResponse(messageInfo, new Subject(), messageLayer, appContext, cbh);
}
{code}
However, section 3.8.3.3 of the JSR 196 (JASPIC) spec says that the semantics of secureResponse are as defined in Section 3.8.2.2, which thus means that secureResponse should be called after a service invocation. Figure 1.1 in Section 1.1 shows this as well, and the general flow as described is Section 3.8 also mentions this.
So, in JBoss the sequence is
{noformat}
validateRequest -> secureResponse -> Invoke Service
{noformat}
While the spec seems to say it should be:
{noformat}
validateRequest -> Invoke Service -> secureResponse
{noformat}
In the reference implementation GlassFish the sequence is indeed the latter one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (AS7-4216) Failure while deploying simple struts app
by Maas van den Berg (JIRA)
[ https://issues.jboss.org/browse/AS7-4216?page=com.atlassian.jira.plugin.s... ]
Maas van den Berg resolved AS7-4216.
------------------------------------
Resolution: Rejected
> Failure while deploying simple struts app
> -----------------------------------------
>
> Key: AS7-4216
> URL: https://issues.jboss.org/browse/AS7-4216
> Project: Application Server 7
> Issue Type: Bug
> Components: Web
> Reporter: Thomas Diesler
> Assignee: Remy Maucherat
>
> {code}
> 14:53:15,474 WARN [com.opensymphony.xwork2.util.FileManager] (MSC service thread 1-1) Could not create JarEntryRevision for [vfs:/content/StrutsBasics.war/WEB-INF/lib/struts2-core-2.2.3.1]!: java.util.zip.ZipException: error in opening zip file
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.6.0_29]
> at java.util.zip.ZipFile.<init>(ZipFile.java:127) [rt.jar:1.6.0_29]
> at java.util.jar.JarFile.<init>(JarFile.java:135) [rt.jar:1.6.0_29]
> at java.util.jar.JarFile.<init>(JarFile.java:99) [rt.jar:1.6.0_29]
> at com.opensymphony.xwork2.util.FileManager$JarEntryRevision.build(FileManager.java:307) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.util.FileManager.loadFile(FileManager.java:145) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.util.FileManager.loadFile(FileManager.java:105) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles(XmlConfigurationProvider.java:898) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadDocuments(XmlConfigurationProvider.java:154) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.init(XmlConfigurationProvider.java:121) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:179) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:66) [xwork-core-2.2.3.1.jar:2.2.3.1]
> at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:380) [struts2-core-2.2.3.1.jar:2.2.3.1]
> at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:424) [struts2-core-2.2.3.1.jar:2.2.3.1]
> at org.apache.struts2.dispatcher.FilterDispatcher.init(FilterDispatcher.java:195) [struts2-core-2.2.3.1.jar:2.2.3.1]
> at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:447) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3269) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3865) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months