[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-4304:
----------------------------------
Assignee: Tomas Hofman (was: Darran Lofthouse)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Tomas Hofman
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-4289:
----------------------------------
Assignee: Jim Ma (was: Tomas Hofman)
> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
> Key: WFLY-4289
> URL: https://issues.jboss.org/browse/WFLY-4289
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Jakub Grabowski
> Assignee: Jim Ma
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3669) Deltaspike deployment fails on wildfly 8.1
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3669?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-3669:
---------------------------------------
What does the structure of your deployment look like?
> Deltaspike deployment fails on wildfly 8.1
> ------------------------------------------
>
> Key: WFLY-3669
> URL: https://issues.jboss.org/browse/WFLY-3669
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Paa Kojo Konduah Amos
> Assignee: Jozef Hartinger
>
> on addition of the Deltaspike-core dependency in my pom.xml....wildfly 8.1 fails at deployment time.
> 01:45:08,481 INFO [org.apache.deltaspike.core.util.ProjectStageProducer] (MSC service thread 1-4) Computed the following DeltaSpike ProjectStage: Production
> 01:45:12,813 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:134)
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:130)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_65]
> ... 3 more
> 01:45:12,824 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jwi.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jwi.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jwi.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]"}}
> 01:45:12,919 INFO [org.jboss.as.server] (ServerService Thread Pool – 28) JBAS018559: Deployed "jwi.war" (runtime-name : "jwi.war")
> 01:45:12,928 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (DROOLS-740) NoSuchMethodError at runtime while evaluating String and Long
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-740?page=com.atlassian.jira.plugin... ]
Toshiya Kobayashi updated DROOLS-740:
-------------------------------------
Description:
When you write a LHS like this,
{noformat}
Person( name == "Elizabeth" + new Long(2L) )
{noformat}
you will face NoSuchMethodError after 20 times evaluation.
{noformat}
testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR!
java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder;
at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294)
at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450)
at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253)
{noformat}
was:
When you write a LHS like this,
{noformat}
Person( name == "Elizabeth" + new Long(2L) )
{noformat}
you will face NoSuchMethodError after 20 evaluation.
{noformat}
testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR!
java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder;
at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294)
at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450)
at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253)
{noformat}
> NoSuchMethodError at runtime while evaluating String and Long
> -------------------------------------------------------------
>
> Key: DROOLS-740
> URL: https://issues.jboss.org/browse/DROOLS-740
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
>
> When you write a LHS like this,
> {noformat}
> Person( name == "Elizabeth" + new Long(2L) )
> {noformat}
> you will face NoSuchMethodError after 20 times evaluation.
> {noformat}
> testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR!
> java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder;
> at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450)
> at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (DROOLS-740) NoSuchMethodError at runtime while evaluating String and Long
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-740:
----------------------------------------
Summary: NoSuchMethodError at runtime while evaluating String and Long
Key: DROOLS-740
URL: https://issues.jboss.org/browse/DROOLS-740
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
When you write a LHS like this,
{noformat}
Person( name == "Elizabeth" + new Long(2L) )
{noformat}
you will face NoSuchMethodError after 20 evaluation.
{noformat}
testJittedConstraintStringAndLong(org.drools.compiler.integrationtests.Misc2Test) Time elapsed: 1.216 sec <<< ERROR!
java.lang.NoSuchMethodError: java.lang.StringBuilder.append(Ljava/lang/Long;)Ljava/lang/StringBuilder;
at ConditionEvaluator80a8832efb1646d488df2cde72963f02.evaluate(Unknown Source)
at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:230)
at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:187)
at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141)
at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60)
at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:294)
at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:255)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:277)
at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:237)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1495)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1450)
at org.drools.compiler.integrationtests.Misc2Test.testJittedConstraintStringAndLong(Misc2Test.java:7253)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (LOGMGR-117) Fork Log4J ConosleAppender to simply handling of calls to System.out
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-117?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-117:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1196228|https://bugzilla.redhat.com/show_bug.cgi?id=1196228] from NEW to ASSIGNED
> Fork Log4J ConosleAppender to simply handling of calls to System.out
> --------------------------------------------------------------------
>
> Key: LOGMGR-117
> URL: https://issues.jboss.org/browse/LOGMGR-117
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Reporter: Kyle Lape
> Assignee: James Perkins
>
> While the use of {{ConsoleAppender}} in Log4J application logging configurations is discouraged, JBoss could probably do a better job of managing its use.
> Currently it's possible to encounter a deadlock if thread A invokes {{System.out.println()}} and thread B invokes {{Logger.info()}}. Thread A will get the lock on {{System.out}} (a {{java.io.PrintWriter}}), but then thread B will get the lock on the {{org.apache.log4j.ConsoleAppender}}. Then each thread is waiting on the other's lock.
> The suggested improvement (discussed with [~jamezp]) is to fork Log4J's {{ConsoleAppender}} so that instead of calling {{System.out.println}}, it calls the real {{stdout}}.
> *Bonus enhancement*: Drop a {{WARN}} message to the system root logger discouraging the use of {{ConsoleAppender}} in application configurations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on WFLY-2129:
------------------------------
https://github.com/wildfly/wildfly/commit/1c56cbacb3699f3d506fd4b2418b575...
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2129
> URL: https://issues.jboss.org/browse/WFLY-2129
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Environment: Mac OS X
> Reporter: Nicky Mølholm
> Assignee: Jim Ma
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc)
> A simple EJB with a Web service view can illustrate the first problem:
> {code:java}
> @Stateless
> @WebService
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> @PermitAll // <-- This doesn't work
> //@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> // <--- unless you put them on class level
> public String sayHello(String name) {
> System.out.println("******** Greeter.sayHello(" + name + ")");
> return "Hello " + name;
> }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll,@DenyAll,@RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-3988) Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3988?page=com.atlassian.jira.plugin.... ]
Jim Ma resolved WFLY-3988.
--------------------------
Resolution: Done
> Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-3988
> URL: https://issues.jboss.org/browse/WFLY-3988
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
>
> Given this endpoint:
> {code:java}
> @Stateless
> @WebService(endpointInterface="com.redhat.gss.SecureEndpoint")
> @DeclareRoles({"a","b"})
> @WebContext(contextRoot="/endpoint",urlPattern="/e",authMethod="BASIC")
> public class SecureEndpointE implements SecureEndpoint {
> @RolesAllowed({"a"})
> public String a() {
> return "Success";
> }
> @RolesAllowed({"b"})
> public String b() {
> return "Success";
> }
> @PermitAll
> public String c() {
> return "Success";
> }
> }
> {code}
> One would expect any authenticated user to be able to invoke {{c()}}, but only users with a role found in {{@DelareRoles}} can invoke it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months