September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1309) Channel binding callback cannot support tls-unique

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1309?page=com.atlassian.jira.plugin.s... ] David Lloyd resolved ELY-1309. ------------------------------ Fix Version/s: 1.1.0.CR4 (was: 1.2.0.Beta5) Assignee: David Lloyd Resolution: Done > Channel binding callback cannot support tls-unique > -------------------------------------------------- > > Key: ELY-1309 > URL: https://issues.jboss.org/browse/ELY-1309 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI, Authentication Client, Authentication Server, Callbacks, SASL > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 1.1.0.CR4 > > > The revised API for the channel binding callback uses SSL sessions, but the standard TLS channel binding types [according to the RFC|https://tools.ietf.org/html/rfc5929] are associated with the connection, not the session. It is likely that the proposed channel bindings JDK API will exist on SSLSocket/SSLEngine. Introduce an API that allows the callback handlers to acquire the connection information using a forward-compatible API. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1736) Create DMN benchmarks

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1736: ------------------------------------- Summary: Create DMN benchmarks Key: DROOLS-1736 URL: https://issues.jboss.org/browse/DROOLS-1736 Project: Drools Issue Type: Task Components: dmn engine Affects Versions: 7.3.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi Fix For: 7.4.0.Final We need to measure DMN runtime and buildtime performance. There is a repository with Drools benchmarks [1]. New benchmarks should be added there. [1] https://github.com/kiegroup/kie-benchmarks -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1173) InvalidNameState not used for non-existing identities in ServerAuthenticationContext

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1173?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1173: ---------------------------------- In this context "invalid name" means that the name did not pass validation. A valid name which is nevertheless not found is not the same issue (as such a name may later be found, for example). I don't think we need a persistent state for not-found names. > InvalidNameState not used for non-existing identities in ServerAuthenticationContext > ------------------------------------------------------------------------------------ > > Key: ELY-1173 > URL: https://issues.jboss.org/browse/ELY-1173 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There was added new state *InvalidNameState* into *ServerAuthenticationContext* as part of ELY-1115, but it is currently used only when principal is rewritten to null - not when identity is not found in security realm. > After adding this will be probably necessary to implement more State methods in *InvalidNameState* to have wildfly tests green. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-744) Create log categories for mechanisms instead of prefixing messages

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-744?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-744: -------------------------------------- +1 I think we need to ensure the parent category remains unchanged but will be good to use more fine grained categories where we have made a decision to call out the mech name. Overall ideally exciting logging config examples should remain unchanged. That is not completely set in stone but if we can retain compatibility we can avoid discussions on compatibility ;-) > Create log categories for mechanisms instead of prefixing messages > ------------------------------------------------------------------ > > Key: ELY-744 > URL: https://issues.jboss.org/browse/ELY-744 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > In log messages are often used prefixes to determine context of the message - typically name of mechanism: > {code:java} > log.trace("ClientCertAuthenticationMechanism: re-authentication succeed"); > {code} > This should be replaced by standalone log categories. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1173) InvalidNameState not used for non-existing identities in ServerAuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1173?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1173: --------------------------------- [~dmlloyd] Do we want to keep InvalidNameState? Not sure if the last discussion about it with you didnt ended that we should not have such state... > InvalidNameState not used for non-existing identities in ServerAuthenticationContext > ------------------------------------------------------------------------------------ > > Key: ELY-1173 > URL: https://issues.jboss.org/browse/ELY-1173 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There was added new state *InvalidNameState* into *ServerAuthenticationContext* as part of ELY-1115, but it is currently used only when principal is rewritten to null - not when identity is not found in security realm. > After adding this will be probably necessary to implement more State methods in *InvalidNameState* to have wildfly tests green. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-744) Create log categories for mechanisms instead of prefixing messages

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-744?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-744: -------------------------------- [~dlofthouse] Do we still want this? If yes, no problem if I give it to intern which just arrived? > Create log categories for mechanisms instead of prefixing messages > ------------------------------------------------------------------ > > Key: ELY-744 > URL: https://issues.jboss.org/browse/ELY-744 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > In log messages are often used prefixes to determine context of the message - typically name of mechanism: > {code:java} > log.trace("ClientCertAuthenticationMechanism: re-authentication succeed"); > {code} > This should be replaced by standalone log categories. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-865) Principal name from realms should not be pure user input

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-865?page=com.atlassian.jira.plugin.sy... ] Jan Kalina closed ELY-865. -------------------------- Resolution: Rejected Regarding discussion above considered not a bug, closing. > Principal name from realms should not be pure user input > -------------------------------------------------------- > > Key: ELY-865 > URL: https://issues.jboss.org/browse/ELY-865 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > All security realm now provides user-provided username as realmIdentity principal. > That can be problem, if identity search is case-insensitive - for example: > * Lets have filesystem realm on windows - user will write "FIRSTuser", because filesystem is caseinsensitive realm will correctly found "firstUser" - but it can obtain two different NamePrincipals - the same user can act as two different users for application running on AS - it can be security problem > * the same problem can occure if LDAP search is case-insensitive - not sure, but I think this is case of Active Directory > * the same can probably occure for JDBC, if database column is defined as case-insensitive -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1173) InvalidNameState not used for non-existing identities in ServerAuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1173?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1173: ---------------------------- Priority: Minor (was: Critical) > InvalidNameState not used for non-existing identities in ServerAuthenticationContext > ------------------------------------------------------------------------------------ > > Key: ELY-1173 > URL: https://issues.jboss.org/browse/ELY-1173 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There was added new state *InvalidNameState* into *ServerAuthenticationContext* as part of ELY-1115, but it is currently used only when principal is rewritten to null - not when identity is not found in security realm. > After adding this will be probably necessary to implement more State methods in *InvalidNameState* to have wildfly tests green. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-808) Password not passed into DatabaseServerLoginModule

by Issa Gueye (JIRA)

[ https://issues.jboss.org/browse/SECURITY-808?page=com.atlassian.jira.plug... ] Issa Gueye updated SECURITY-808: -------------------------------- > Password not passed into DatabaseServerLoginModule > -------------------------------------------------- > > Key: SECURITY-808 > URL: https://issues.jboss.org/browse/SECURITY-808 > Project: PicketBox > Issue Type: Bug > Environment: WildFly8 on Windows 7 64-bit > Reporter: Stefan Eder > Assignee: Stefan Guilhen > Priority: Critical > > Trying to migrate an application to WildFly (from AS6.1) the migration went pretty smooth except for using the security domain. > The application uses a the ClientLoginModule on the client side and the DatabaseserverLoginModule on the server side. > > Though the DatabaseServerLoginModule is called the validation of the password fails. I debugged it and the reason seems to be that in {{org.jboss.security.auth.callback.JBossCallbackHandler.getPassword()}} a {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is not handled and hence instead of a password the String {{org.jboss.as.security.remoting.RemotingConnectionCredential@22341334}} is passed through to the DatabaseLoginModule. > See also [DatabaseServerLoginModule broken?|https://community.jboss.org/message/863295] and the related posts -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9360) Upgrade Generic JMS RA 2.0.1.Final

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-9360?page=com.atlassian.jira.plugin.... ] Jeff Mesnil edited comment on WFLY-9360 at 9/19/17 8:34 AM: ------------------------------------------------------------ TCK 7 tests that are fixed by the Generic JMS RA 2.0.1.Final: * [core.queueConnection] ** fixed by https://github.com/jms-ra/generic-jms-ra/pull/20 * [core.topicConnection] * fixed by https://github.com/jms-ra/generic-jms-ra/pull/20 * [jms.ee.ejb.sessionTtests] * clientID not set on the pooled-connection-factory dscf => requires change to the standalone-full-tck7 configuration * [jms.ee.mdb.xa] * NOT FIXED * related to JBEAP-13128 - Tibco 8 XA CF does not allow to create plain JMS Context * session will be non-xa or xa depending on an active tx. But Tibco 8 XA CF can not create plain JMS Context (that is created when the managed connection will create JMS resources (session & jms * [core20] * JMSSecurityException fixed by https://github.com/jms-ra/generic-jms-ra/pull/21 * [ee20.cditests] * some are NOT FIXED (caused by JBEAP-13128 - Tibco 8 XA CF does not allow to create plain JMS Context) was (Author: jmesnil): TCK 7 tests that are fixed by the Generic JMS RA 2.0.1.Final: * [core.queueConnection] * fixed by https://github.com/jms-ra/generic-jms-ra/pull/20 * [core.topicConnection] * fixed by https://github.com/jms-ra/generic-jms-ra/pull/20 * [jms.ee.ejb.sessionTtests] * clientID not set on the pooled-connection-factory dscf => requires change to the standalone-full-tck7 configuration * [jms.ee.mdb.xa] * NOT FIXED * related to JBEAP-13128 - Tibco 8 XA CF does not allow to create plain JMS Context * session will be non-xa or xa depending on an active tx. But Tibco 8 XA CF can not create plain JMS Context (that is created when the managed connection will create JMS resources (session & jms * [core20] * JMSSecurityException fixed by https://github.com/jms-ra/generic-jms-ra/pull/21 * [ee20.cditests] * some are NOT FIXED (caused by JBEAP-13128 - Tibco 8 XA CF does not allow to create plain JMS Context) > Upgrade Generic JMS RA 2.0.1.Final > ---------------------------------- > > Key: WFLY-9360 > URL: https://issues.jboss.org/browse/WFLY-9360 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 11.0.0.CR1 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > The 2.0.1.Final release addresses issues raised by running the TCK with Tibco 8 as the JMS broker behind the Generic JMS RA -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 September 2017