[JBoss JIRA] (WFLY-8252) HttpServletRequest.logout() doesn't work with Elytron
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8252:
---------------------------------
Summary: HttpServletRequest.logout() doesn't work with Elytron
Key: WFLY-8252
URL: https://issues.jboss.org/browse/WFLY-8252
Project: WildFly
Issue Type: Bug
Components: Web (Undertow), Security
Reporter: Josef Cacek
Assignee: Stuart Douglas
Priority: Blocker
Calling {{HttpServletRequest.logout()}} leaves user logged in if Elytron security is used.
This means security flaw, therefor setting priority to blocker.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2292 at 2/27/17 3:44 PM:
-------------------------------------------------------------------
I'm rejecting the PR to get this issue in the correct state because at this stage the PR says Do not Merge.
was (Author: brian.stansberry):
I'm rejecting the PR to get this issue in the correct because at this stage the PR says Do not Merge.
> HTTPS / Native Management protocol mismatch when using SSL
> ----------------------------------------------------------
>
> Key: WFCORE-2292
> URL: https://issues.jboss.org/browse/WFCORE-2292
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large.
> 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl@2ab25536
> 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@787e0a1f
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192])
> ^^^^^^^
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192]
> 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF
> 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream
> 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@1cc4241b
> This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with:
> ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password
> Relevant bits of config in use:
> {quote}
> <management>
> <security-realms>
> <security-realm name="sslSecurityRealm">
> <server-identities>
> <ssl>
> <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/>
> </ssl>
> </server-identities>
> <authentication>
> <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/>
> </authentication>
> </security-realm>
> </security-realms>
> <management-interfaces>
> <native-interface security-realm="sslSecurityRealm">
> <socket-binding native="native"/>
> </native-interface>
> </management-interfaces>
> </management>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/>
> </socket-binding-group>
> {quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8238) Unable to undefine credential-reference
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8238?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-8238:
------------------------------------
[~thofman], will you take care globally, as in case of WFLY-8070 ?
> Unable to undefine credential-reference
> ---------------------------------------
>
> Key: WFLY-8238
> URL: https://issues.jboss.org/browse/WFLY-8238
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Security
> Reporter: Claudio Miranda
> Assignee: Tomas Hofman
>
> A bridge is added and a credential-reference is set.
> However a "password" attribute cannot be set as the alternatives constraint validates the data, but the password attribute has a default value.
> Also neither credential-reference and password are required=true, so they may be undefined.
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:write-attribute(name=credential-reference,value={clear-text=senha1})
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=credential-reference)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (credential-reference) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
> The same problem, when user adds a bridge with a password and later wants to undefine it to add a credential-reference
> {code}
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:add(discovery-group=mane,queue-name=DLQ,forwarding-address=DLQ,password=senha1)
> /profile=full/subsystem=messaging-activemq/server=default/bridge=test1:undefine-attribute(name=password)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYMSGAMQ0069: Attribute (password) can not been undefined as the resource does not define any alternative to this attribute."},
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (SECURITY-811) NullPointerException in DeploymentRoleToRolesMappingProvider
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-811?page=com.atlassian.jira.plug... ]
Stefan Guilhen resolved SECURITY-811.
-------------------------------------
Fix Version/s: PicketBox_5_0_0.Beta1
Resolution: Done
> NullPointerException in DeploymentRoleToRolesMappingProvider
> ------------------------------------------------------------
>
> Key: SECURITY-811
> URL: https://issues.jboss.org/browse/SECURITY-811
> Project: PicketBox
> Issue Type: Bug
> Components: JBossSX
> Affects Versions: JBossSecurity_2.0.8.Final
> Reporter: Chao Wang
> Assignee: Peter Skopek
> Priority: Minor
> Fix For: PicketBox_5_0_0.Beta1
>
> Attachments: SECURITY-811-picketbox.patch, SECURITY-811.patch
>
>
> {code:title=DeploymentRoleToRolesMappingProvider.java|borderStyle=solid}
> RoleGroup assignedRoles = (SimpleRoleGroup)contextMap.get(SecurityConstants.ROLES_IDENTIFIER);
> for (Role r: assignedRoles.getRoles()) {
> {code}
> A null value of assignedRoles causes NullPointerException on server if user have not input username / passoword yet
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (SECURITY-913) NPE if use LdapExtLoginModule in j2se
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-913?page=com.atlassian.jira.plug... ]
Stefan Guilhen resolved SECURITY-913.
-------------------------------------
Fix Version/s: PicketBox_5_0_0.Beta1
(was: PicketBox_5_0_0.Alpha1)
Resolution: Done
> NPE if use LdapExtLoginModule in j2se
> -------------------------------------
>
> Key: SECURITY-913
> URL: https://issues.jboss.org/browse/SECURITY-913
> Project: PicketBox
> Issue Type: Enhancement
> Components: JBossSX
> Affects Versions: PicketBox_5_0_0.Alpha1
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: PicketBox_5_0_0.Beta1
>
> Attachments: picketbox-j2se.zip
>
>
> Use LdapExtLoginModule in j2se with condifg:
> {code}
> <?xml version='1.0'?>
>
> <policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:jboss:security-config:5.0"
> xmlns="urn:jboss:security-config:5.0"
> xmlns:jbxb="urn:jboss:security-config:5.0">
>
> <application-policy name = "Sample-Ldap">
> <authentication>
> <login-module code = "org.jboss.security.auth.spi.LdapExtLoginModule" flag = "required">
> <module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
> <module-option name="java.naming.provider.url">ldap://10.66.218.46:389</module-option>
> <module-option name="java.naming.security.authentication">simple</module-option>
> <module-option name="bindDN">cn=Manager,dc=example,dc=com</module-option>
> <module-option name="bindCredential">redhat</module-option>
> <module-option name="baseCtxDN">ou=Customers,dc=example,dc=com</module-option>
> <module-option name="baseFilter">(uid={0})</module-option>
> <module-option name="rolesCtxDN">ou=Roles,dc=example,dc=com</module-option>
> <module-option name="roleFilter">(uniqueMember={1})</module-option>
> <module-option name="roleAttributeID">cn</module-option>
> </login-module>
> </authentication>
> </application-policy>
>
> </policy>
> {code}
> authentication parse section code [1] line 123:
> {code}
> AuthenticationInfo authInfo = new AuthenticationInfo();
> {code}
> which this cause null set as AuthenticationInfo name, then cause 'jboss.security.security_domain=null' as options be passed to LdapExtLoginModule, this null value finally cause NPE in LdapExtLoginModule line around 840
> {code}
> Entry entry = (Entry) iter.next();
> env.put(entry.getKey(), entry.getValue());
> {code}
> [1] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbos...
> [2] https://github.com/picketbox/picketbox/blob/master/security-jboss-sx/jbos...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (SECURITY-955) Regression in parsing username in LdapExtLoginModule
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-955?page=com.atlassian.jira.plug... ]
Stefan Guilhen closed SECURITY-955.
-----------------------------------
Fix Version/s: PicketBox_5_0_0.Beta1
Resolution: Done
The commit that was missing in PicketBox/master was merged.
> Regression in parsing username in LdapExtLoginModule
> ----------------------------------------------------
>
> Key: SECURITY-955
> URL: https://issues.jboss.org/browse/SECURITY-955
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_5_0_0.Alpha3
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Blocker
> Fix For: PicketBox_5_0_0.Beta1
>
>
> In case when customers using LdapExtLoginModule with option parseUsername=true but without option usernameBeginString (i.e. usernameBeginString=null) then all users cannot be successfully authenticated into application. Authentication failure is caused by hidden internal NPE.
> It is the same issue as was reported in [1], but fix is missing in current EAP 7.1 version of PicketBox (5.0.0.Alpha3).
> We request blocker flag because:
> * Valid configuration which works for 7.0.x becomes invalid after migration to 7.1.0
> * All users cannot authenticate to application despite of valid EAP configuration
> * Authetication failure caused by NPE is logged to server log
> Thrown NPE:
> {code}
> java.lang.NullPointerException
> at org.jboss.security.auth.spi.LdapExtLoginModule.getUsername(LdapExtLoginModule.java:963)
> at org.jboss.security.auth.spi.LdapExtLoginModule.validatePassword(LdapExtLoginModule.java:342)
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:283)
> {code}
> [1] https://issues.jboss.org/browse/JBEAP-364?focusedCommentId=13160168&page=...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1451) NPE when building KieBase with OOPath in a declared window
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1451?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1451:
-------------------------------------
Since an oopath constraint is implemented through one or more FromNode it is not technically possible to allow to use it inside a declared window, in the same way as a declared window cannot contain a join condition.
In fact to let this work the resulting rete network should be something like:
{code}
[EntryPointNode(1) EntryPoint::DEFAULT ] on Partition(MAIN)
[ObjectTypeNode(2)::EntryPoint::DEFAULT objectType=[ClassObjectType class=org.drools.core.reteoo.InitialFactImpl] expiration=-1ms ] on Partition(MAIN)
[LeftInputAdapterNode(5)] on Partition(1)
[JoinNode(6) - [ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent]] on Partition(1)
[ReactiveFromNode(7) :: MessageEvent/getMsg{message == "Ping"}] on Partition(1)
[RuleTerminalNode(8): rule=R] on Partition(1)
[ObjectTypeNode(3)::EntryPoint::DEFAULT objectType=[ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent] expiration=3000ms ] on Partition(MAIN)
[WindowNode(4) constraints=[]] on Partition(1)
[JoinNode(6) - [ClassObjectType event=org.drools.testcoverage.common.model.MessageEvent]] on Partition(1)
{code}
with the WindowNode feeding the JoinNode of the rule where the declared window is used and the ReactiveFromNode implementing the oopath, below that JoinNode itself. This is clearly not possible.
> NPE when building KieBase with OOPath in a declared window
> ----------------------------------------------------------
>
> Key: DROOLS-1451
> URL: https://issues.jboss.org/browse/DROOLS-1451
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Beta6
> Environment: Reproducible with 7.0.0-SNAPSHOT.
> Reporter: Marek Winkler
> Assignee: Mario Fusco
> Attachments: oopath-cep-stacktrace.txt
>
>
> When using an OOPath expression in a declared window (does not matter if a length or a time window), a NPE is thrown. For instance, a rule such as:
> {code}
> declare window Pings
> MessageEvent( /msg{ message == 'Ping' } ) over window:length( 2 )
> end
> rule R when
> $messageEvent: MessageEvent() from window Pings
> then
> events.add( $messageEvent );
> end
> {code}
> produces the following exception (see the attachment for the full stacktrace) when building the KieBase:
> {code}
> java.lang.NullPointerException
> at org.drools.core.reteoo.builder.WindowReferenceBuilder.build(WindowReferenceBuilder.java:40)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:116)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:77)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:164)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:136)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
> ...
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:630)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8241) EJB deployments with Elytron SD collides in EJB3 SD service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-8241:
----------------------------------
Thanks, confirmed. I was using old build. Sorry.
> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
> Key: WFLY-8241
> URL: https://issues.jboss.org/browse/WFLY-8241
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
> Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-8241) EJB deployments with Elytron SD collides in EJB3 SD service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-8241?page=com.atlassian.jira.plugin.... ]
Jan Kalina closed WFLY-8241.
----------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Duplicate Issue
> EJB deployments with Elytron SD collides in EJB3 SD service
> -----------------------------------------------------------
>
> Key: WFLY-8241
> URL: https://issues.jboss.org/browse/WFLY-8241
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
> Attachments: enable-elytron.cli, read-props-grant.ear, read-props-limited.ear
>
>
> Every EJB deployment associated with an Elytron security domain builds *jboss.ejb3.security-domain* service:
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
> But it fails if there are more such deployments, because it mean second service with the same name:
> {code}
> 00:02:12,118 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."read-props-limited.ear"."ejb-moduleread-props-limited.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of subdeployment "ejb-moduleread-props-limited.jar" of deployment "read-props-limited.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.ejb3.security-domain is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2555)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.ejb3.deployment.processors.EJBDefaultSecurityDomainProcessor.deploy(EJBDefaultSecurityDomainProcessor.java:111)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months