[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext
by Alessandro Moscatelli (Jira)
[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli resolved WFLY-10417.
------------------------------------------
Fix Version/s: 15.0.0.Final
Resolution: Done
> Security API - Soteria - Jaspic - Error getting ServerAuthContext
> -----------------------------------------------------------------
>
> Key: WFLY-10417
> URL: https://issues.jboss.org/browse/WFLY-10417
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1, 14.0.0.Final
> Environment: Wildfly 13.0.0.Beta1 and an EAR Application using JavaEE 8 Security API
> Reporter: Alessandro Moscatelli
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 15.0.0.Final
>
> Attachments: image-2018-05-24-13-41-05-322.png, soteria.zip
>
>
> I am testing the new Wildfly release and the new Java EE8 Security API.
> I noticed this serious (I truly believe) bug, and it also accours almost randomly.
>
> The deployed application is an EAR.
>
> If I deploy the EAR with a started Wildfly 13.0.0.Beta1 everything is fine.
> Then if I stop and start / restart the application server, I can see the startup and the EAR is redeployed but sometimes (like 50% of time) the bug/error accours.
> Usually after a couple of times (stop/start/restart) I can reproduce the issue.
> Before the bug accours every call to pages and APIs works correctly. After the bug accours every call triggers the AuthException.
> After the bug accours, if I redeploy the SAME EAR everything is fine again 100% of times.
> This seems like Wildfly does something different when redeploying an application on startup and when being already startup up and then processing an application deploy.
>
> I can provide my EAR if you want, but I would prefer not to if this is not necessary.
> The security domain as defined as suggested :
> {code:xml}
> <security-domain name="auth" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
> {code}
>
> META-INF/jboss-app.xml inside the EAR :
>
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app>
> <security-domain>auth</security-domain>
> </jboss-app>
> {code}
>
> META-INF/jboss-web.xml inside the WAR inside the EAR :
>
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>auth</security-domain>
> </jboss-web>
> {code}
>
> Log :
> {code}
> 17:04:18,556 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /optoplus-services-web and security domain auth: javax.security.auth.message.AuthException
> at org.jboss.security.auth.message.config.JBossServerAuthConfig.getAuthContext(JBossServerAuthConfig.java:187)
> at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:99)
> at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:123)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> UPDATE !!
> Now I finally got WHY it was random !!
> The problem is related to EAR containing multiple WAR registering different contexts :
> {code}
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 80) Initializing Soteria 1.0 for context '/soteria-web2'
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 76) Initializing Soteria 1.0 for context '/soteria-web'
> 13:29:37,738 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/soteria-web2' for server 'default-server'
> 13:29:37,745 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/soteria-web' for server 'default-server'
> 13:29:37,781 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "soteria-ear-1.0.0.ear" (runtime-name : "soteria-ear-1.0.0.ear")
> 13:29:37,908 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Beta1 (WildFly Core 5.0.0.Beta3) started in 10500ms - Started 707 of 931 services (430 services are lazy, passive or on-demand)
> 13:30:09,195 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /soteria-web and security domain auth: javax.security.auth.message.AuthException
> {code}
> *+In case of a reboot (or stop and start) of Wildfly, only ONE of the TWO contexts manages to get the ServerAuthContext !+*
> I attached an example project you can use to reproduce and detailed steps !
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3398) Remove duplicated code
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3398?page=com.atlassian.jira.plugi... ]
Daniele Zonca updated DROOLS-3398:
----------------------------------
Description:
During various refactoring, differente methods/implementations get duplkicated all over the code - especially inside the Command stack.
Find and remove duplication,. eventually moving code in common/static methods
*Specs*
- Remove enable/disable methods from org.drools.workbench.screens.scenariosimulation.client.rightpanel.ListGroupItemView and relative implementation (ListGroupItemViewImpl) and usages because the implementation is empty
- Cleanup org.drools.workbench.screens.scenariosimulation.client.popup.ScenarioConfirmationPopupViewTest: setup() and unused field
- Refactor most execution logic of org.drools.workbench.screens.scenariosimulation.client.commands.actualcommands.PrependColumnCommand and org.drools.workbench.screens.scenariosimulation.client.commands.actualcommands.AppendColumnCommand to a method in a new common abstract class
was:
During various refactoring, differente methods/implementations get duplkicated all over the code - especially inside the Command stack.
Find and remove duplication,. eventually moving code in common/static methods
> Remove duplicated code
> ----------------------
>
> Key: DROOLS-3398
> URL: https://issues.jboss.org/browse/DROOLS-3398
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Anna Baker
> Priority: Minor
>
> During various refactoring, differente methods/implementations get duplkicated all over the code - especially inside the Command stack.
> Find and remove duplication,. eventually moving code in common/static methods
> *Specs*
> - Remove enable/disable methods from org.drools.workbench.screens.scenariosimulation.client.rightpanel.ListGroupItemView and relative implementation (ListGroupItemViewImpl) and usages because the implementation is empty
> - Cleanup org.drools.workbench.screens.scenariosimulation.client.popup.ScenarioConfirmationPopupViewTest: setup() and unused field
> - Refactor most execution logic of org.drools.workbench.screens.scenariosimulation.client.commands.actualcommands.PrependColumnCommand and org.drools.workbench.screens.scenariosimulation.client.commands.actualcommands.AppendColumnCommand to a method in a new common abstract class
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3406) [DMN Designer] Decision Service splitter should be movable
by Roger Martínez (Jira)
[ https://issues.jboss.org/browse/DROOLS-3406?page=com.atlassian.jira.plugi... ]
Roger Martínez edited comment on DROOLS-3406 at 12/14/18 8:50 PM:
------------------------------------------------------------------
Hey [~manstis], here are some comments:
* If you recall correctly in Stunner we have "viewers", "editors", and other kind of "working modes" available. So they way this works is usually via "CanvasControl"'s, by enabling or disabling them for each case, or at least that's the way it was initially designed... hehe. So this is why I would recommend doing your work, if makes sense, by mixing code in some existing/new canvas control type and/or the shape view instance if self. This way, for example, you can just enable your control in case of edit mode, and keep it not available when just "vieweing" the diagram
* This way the idea is to add as much logic as possible in the CanvasControl rather than in the ShapeView itself, allowing this way to handle this new feature with the canvas control API. For example we use to handle all events and user interactions in the control classes, rather than on the shape views
* Anyway I know that the world is not ideal and sometimes it's necessary to add custom logic on top of the ShapeView, which is also usually built and generated automatically by the SVG annotation processor. This ability was also missing for the new Case Modeller editor, which is using SVG views and also provides custom logic on top of ShapeView. So you can do this, if applies for you, in the same way. The idea is:
** Create a custom _ShapeViewBuilder_ and use in your _SVGViewFactory_ declaration, by specifying it in the _builder_ field. Eg: [CaseManagementSVGViewFactory|https://github.com/kiegroup/kie-wb-common/bl...]
** This way you can also create a custom ShapeView type, for example as the [CaseManagementShapeView|https://github.com/kiegroup/kie-wb-common/blob/ma...], which is being built in your custom _ShapeViewBuilder_.
** By following this, you can then _cast_ the _ShapeView_, in your _CanvasHandler_ type or any of your custom components, from ShapeView to your concrete implementation.
So hope this helps a bit. Feel tree to ask for whatever you need or if any Qs, np!!
Thanks!
was (Author: roger600):
Hey [~manstis], here are some comments:
* If you recall correctly in Stunner we have "viewers", "editors", and other kind of "working modes" available. So they way this works is usually via "CanvasControl"'s, by enabling or disabling them for each case, or at least that's the way it was initially designed... hehe. So this is why I would recommend doing your work, if makes sense, by mixing code in some existing/new canvas control type and/or the shape view instance if self. This way, for example, you can just enable your control in case of edit mode, and keep it not available when just "vieweing" the diagram
* This way the idea is to add as much logic as possible in the CanvasControl rather than in the ShapeView itself, allowing this way to handle this new feature with the canvas control API. For example we use to handle all events and user interactions in the control classes, rather than on the shape views
* Anyway I know that word is not ideal and sometimes it's necessary to add custom logic on top of the ShapeView, which is also usually built and generated automatically by the SVG annotation processor. This ability was also missing for the new Case Modeller editor, which is using SVG views and also provides custom logic on top of ShapeView. So you can do this, if applies for you, in the same way. The idea is:
** Create a custom _ShapeViewBuilder_ and use in your _SVGViewFactory_ declaration, by specifying it in the _builder_ field. Eg: [CaseManagementSVGViewFactory|https://github.com/kiegroup/kie-wb-common/bl...]
** This way you can also create a custom ShapeView type, for example as the [CaseManagementShapeView|https://github.com/kiegroup/kie-wb-common/blob/ma...], which is being built in your custom _ShapeViewBuilder_.
** By following this, you can then _cast_ the _ShapeView_, in your _CanvasHandler_ type or any of your custom components, from ShapeView to your concrete implementation.
So hope this helps a bit. Feel tree to ask for whatever you need or if any Qs, np!!
Thanks!
> [DMN Designer] Decision Service splitter should be movable
> ----------------------------------------------------------
>
> Key: DROOLS-3406
> URL: https://issues.jboss.org/browse/DROOLS-3406
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.15.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
>
> The _splitter_ within a Decision Service is static.
> It needs to be movable (vertically) maintaining it's alignment with the Decision Service bounds. At this point we need to either decide to add _result_ decision(s) and _encapsulated_ decisions to the Decision Service by Command (depending on where the node is dropped) or update the Marshaller to determine the type of decision based on its vertical positioning and location of the _splitter_.
> h2. Acceptance test
> Decision state is updated according to _splitter_ movement. Example if area of result decision expanded so some decision belongs there now, this decision should have state _rusult decision_
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-234) Remove the NullHandler and the FlushableClosable
by James Perkins (Jira)
James Perkins created LOGMGR-234:
------------------------------------
Summary: Remove the NullHandler and the FlushableClosable
Key: LOGMGR-234
URL: https://issues.jboss.org/browse/LOGMGR-234
Project: JBoss Log Manager
Issue Type: Task
Components: core
Reporter: James Perkins
Assignee: James Perkins
The {{NullHandler}} is only used in a test which can easily changed. Therefore the handler should be removed as it likely doesn't server much purpose.
The {{FlushableCloseable}} is just an interface which extends the {{java.io.Closeable}} and {{java.io.Flushable}} interfaces. Types should just extend the JDK provided interfaces and the {{FlushableClosable}} interface should be removed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-233) Move select handlers from core to ext
by James Perkins (Jira)
James Perkins created LOGMGR-233:
------------------------------------
Summary: Move select handlers from core to ext
Key: LOGMGR-233
URL: https://issues.jboss.org/browse/LOGMGR-233
Project: JBoss Log Manager
Issue Type: Task
Components: core, ext
Reporter: James Perkins
Assignee: James Perkins
The following handlers should be moved from the core module to the ext module:
* {{AsyncHandler}}
* {{PeriodicRotatingFileHandler}}
* {{PeriodicSizeRotatingFileHandler}}
* {{QueueHandler}}
* {{SizeRotatingFileHandler}}
* {{SocketHandler}}
* {{SyslogHandler}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-233) Move select handlers from core to ext
by James Perkins (Jira)
[ https://issues.jboss.org/browse/LOGMGR-233?page=com.atlassian.jira.plugin... ]
James Perkins updated LOGMGR-233:
---------------------------------
Fix Version/s: 3.0.0.Final
> Move select handlers from core to ext
> -------------------------------------
>
> Key: LOGMGR-233
> URL: https://issues.jboss.org/browse/LOGMGR-233
> Project: JBoss Log Manager
> Issue Type: Task
> Components: core, ext
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Fix For: 3.0.0.Final
>
>
> The following handlers should be moved from the core module to the ext module:
> * {{AsyncHandler}}
> * {{PeriodicRotatingFileHandler}}
> * {{PeriodicSizeRotatingFileHandler}}
> * {{QueueHandler}}
> * {{SizeRotatingFileHandler}}
> * {{SocketHandler}}
> * {{SyslogHandler}}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (LOGMGR-232) Move the JSON and XML handlers to the ext module
by James Perkins (Jira)
James Perkins created LOGMGR-232:
------------------------------------
Summary: Move the JSON and XML handlers to the ext module
Key: LOGMGR-232
URL: https://issues.jboss.org/browse/LOGMGR-232
Project: JBoss Log Manager
Issue Type: Task
Components: core, ext
Reporter: James Perkins
Assignee: James Perkins
Currently the {{JsonFormatter}} and {{XmlFormatter}} are in the core formatters. These should be moved to the ext module to reduce the size of the core moduel.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months