February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8206) Add Elytron SecurityIdentity support to EE ContextServiceImpl

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-8206: -------------------------------------- Summary: Add Elytron SecurityIdentity support to EE ContextServiceImpl Key: WFLY-8206 URL: https://issues.jboss.org/browse/WFLY-8206 Project: WildFly Issue Type: Task Components: EE, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7322) LDAP referrals does not work in Elytron ldap-realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7322?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7322: ---------------------------------- Should be resolved after merging of ELY-971 > LDAP referrals does not work in Elytron ldap-realm > -------------------------------------------------- > > Key: WFLY-7322 > URL: https://issues.jboss.org/browse/WFLY-7322 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > LDAP referrals cannot be used in Elytron {{ldap-realm}}. Ldap Realm is currently not prepared to work with referrals at all: > * {{ldap-realm}} does not include any options which enable working with LDAP referrals (PicketBox use {{baseFilter}} option which can be configured to return also referral object) > * implementation of {{org.wildfly.security.auth.realm.ldap.LdapSecurityRealm}} does not include any logic which handles referrals > Referrals are important feature of LDAP. It has to be covered by Elytron => requested blocker flag. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8183) Anonymous Elytron SASL authentication fails for JMS

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8183?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-8183. ------------------------------- Resolution: Duplicate Issue > Anonymous Elytron SASL authentication fails for JMS > --------------------------------------------------- > > Key: WFLY-8183 > URL: https://issues.jboss.org/browse/WFLY-8183 > Project: WildFly > Issue Type: Bug > Components: JMS, Security > Reporter: Josef Cacek > Assignee: Jeff Mesnil > Priority: Blocker > > Anonymous JMS client access is not possible with Elytron. > When the ANONYMOUS SASL mechanism is configured, then creating A-MQ session fails with: > {code} > 22:06:26,119 ERROR [org.apache.activemq.artemis.core.server] (default I/O-3) AMQ224018: Failed to create session: java.lang.IllegalArgumentException: Parameter 'guess' may not be null > at org.wildfly.common.Assert.checkNotNullParamChecked(Assert.java:70) > at org.wildfly.common.Assert.checkNotNullParam(Assert.java:48) > at org.wildfly.security.evidence.PasswordGuessEvidence.<init>(PasswordGuessEvidence.java:40) > at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.authenticate(ElytronSecurityManager.java:87) > at org.wildfly.extension.messaging.activemq.ElytronSecurityManager.validateUser(ElytronSecurityManager.java:62) > at org.apache.activemq.artemis.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:132) > at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createSession(ActiveMQServerImpl.java:1278) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handleCreateSession(ActiveMQPacketHandler.java:156) > at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQPacketHandler.handlePacket(ActiveMQPacketHandler.java:81) > at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:627) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:373) > at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:356) > at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:621) > at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350) > at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:293) > at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:267) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358) > at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350) > at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372) > at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358) > at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926) > at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:443) > at org.xnio.netty.transport.AbstractXnioSocketChannel$ReadListener.handleEvent(AbstractXnioSocketChannel.java:379) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:567) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2317) Nested attributes are not validated

by Michal Petrov (JIRA)

Michal Petrov created WFCORE-2317: ------------------------------------- Summary: Nested attributes are not validated Key: WFCORE-2317 URL: https://issues.jboss.org/browse/WFCORE-2317 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha25 Reporter: Michal Petrov Assignee: Brian Stansberry Attributes of type Object do not have their inner attributes validated for e.g. "requires" and "alternatives". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8141) CachedConnectionManager add operation excepts no parameters anymore

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8141?page=com.atlassian.jira.plugin.... ] Stefano Maestri commented on WFLY-8141: --------------------------------------- [~brian.stansberry] I haven't any objection. o ahead, and let me know if/how I can help you. > CachedConnectionManager add operation excepts no parameters anymore > ------------------------------------------------------------------- > > Key: WFLY-8141 > URL: https://issues.jboss.org/browse/WFLY-8141 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > Priority: Critical > > Fix for WFLY-2640 broke :add operation for cached-connection-manager > scipts that do > {noformat} > /profile=default-web/subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true") > {noformat} > {noformat} > /subsystem=jca/cached-connection-manager=cached-connection-manager:add(install="true") > {noformat} > now fail with > {{Operation 'add' does not expect any property.}} > This breaks our quickstarts -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8205) work-manager and distributed-workmanager need an Elytron-enabled flag

by Martin Simka (JIRA)

Martin Simka created WFLY-8205: ---------------------------------- Summary: work-manager and distributed-workmanager need an Elytron-enabled flag Key: WFLY-8205 URL: https://issues.jboss.org/browse/WFLY-8205 Project: WildFly Issue Type: Bug Components: JCA Reporter: Martin Simka Assignee: Flavia Rainone Priority: Blocker 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has ElytronEnabled==false. We have a problem in this line: https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely. I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8204) work-manager and distributed-workmanager need an Elytron-enabled flag

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.... ] Stefano Maestri updated WFLY-8204: ---------------------------------- Component/s: JCA > work-manager and distributed-workmanager need an Elytron-enabled flag > --------------------------------------------------------------------- > > Key: WFLY-8204 > URL: https://issues.jboss.org/browse/WFLY-8204 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Flavia Rainone > Priority: Blocker > > 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has ElytronEnabled==false. We have a problem in this line: > https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... > When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely. > I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8204) work-manager and distributed-workmanager need an Elytron-enabled flag

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.... ] Stefano Maestri updated WFLY-8204: ---------------------------------- Labels: elytron_integration (was: ) > work-manager and distributed-workmanager need an Elytron-enabled flag > --------------------------------------------------------------------- > > Key: WFLY-8204 > URL: https://issues.jboss.org/browse/WFLY-8204 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Flavia Rainone > Priority: Blocker > Labels: elytron_integration > > 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has ElytronEnabled==false. We have a problem in this line: > https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... > When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely. > I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8204) work-manager and distributed-workmanager need an Elytron-enabled flag

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8204?page=com.atlassian.jira.plugin.... ] Stefano Maestri reassigned WFLY-8204: ------------------------------------- Assignee: Flavia Rainone (was: Jason Greene) > work-manager and distributed-workmanager need an Elytron-enabled flag > --------------------------------------------------------------------- > > Key: WFLY-8204 > URL: https://issues.jboss.org/browse/WFLY-8204 > Project: WildFly > Issue Type: Bug > Reporter: Stefano Maestri > Assignee: Flavia Rainone > Priority: Blocker > > 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has ElytronEnabled==false. We have a problem in this line: > https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... > When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely. > I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8204) work-manager and distributed-workmanager need an Elytron-enabled flag

by Stefano Maestri (JIRA)

Stefano Maestri created WFLY-8204: ------------------------------------- Summary: work-manager and distributed-workmanager need an Elytron-enabled flag Key: WFLY-8204 URL: https://issues.jboss.org/browse/WFLY-8204 Project: WildFly Issue Type: Bug Reporter: Stefano Maestri Assignee: Jason Greene Priority: Blocker 2 RA using the same bootStrapContext and so the same WorkManager. First RA has ElytronEnabled==true, while the second one has ElytronEnabled==false. We have a problem in this line: https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/or... When second RA will be deployed it will find security integration set for elytron not according to its configuration. And, since this method is changing securityIntegration on a deployment it would be a problem every time we have mixed configuration w/ and w/o Ely. I think we should have elytron-enabled parameter also in workmanager/default-workmanager in jca subsytem and a check (in the method linked above and/or maybe elsewhere...I need to double check) that RA w/ elytron-enabled use only workmanager w/ elytron-enabled and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2017