May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8676) Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8676?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-8676: ---------------------------------- Although RemoteIdentityTestCase passes when run individually, it now fails in the full -Delytron CI run so we should leave it ignored for now. > Unignore RunAsEjbMdbTestCase and RemoteIdentityTestCase for the Elytron profile > ------------------------------------------------------------------------------- > > Key: WFLY-8676 > URL: https://issues.jboss.org/browse/WFLY-8676 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Farah Juma > Assignee: Farah Juma > > Since WFLY-8414 has been fixed, these tests now pass with the Elytron profile enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Ricardo Martin Camarero (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Ricardo Martin Camarero updated SECURITY-921: --------------------------------------------- > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > Fix For: Negotiation_3_0_4_Final, Negotiation_2_3_13_Final > > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1139) External SASL mechanism does not use a Principal

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1139?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1139: ---------------------------------- Priority: Critical (was: Major) > External SASL mechanism does not use a Principal > ------------------------------------------------ > > Key: ELY-1139 > URL: https://issues.jboss.org/browse/ELY-1139 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta41 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1139) External SASL mechanism does not use a Principal

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1139: ------------------------------------- Summary: External SASL mechanism does not use a Principal Key: ELY-1139 URL: https://issues.jboss.org/browse/ELY-1139 Project: WildFly Elytron Issue Type: Bug Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta41 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-8706: -------------------------------------- Looks as the nodes have not discovered each other. Anyway, place for discussion is the forum, not issue tracker. > Singleton deployments does not work in domain mode > -------------------------------------------------- > > Key: WFLY-8706 > URL: https://issues.jboss.org/browse/WFLY-8706 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Environment: Centos > Wildfly 10.1.0.Final (two instances and one domain controller) > Java 8 > Reporter: Ariel Carrera > Assignee: Paul Ferraro > > In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console. > When a deployments needs to be updated, a race condition happens and two instances of the deployment are started. > From logs: > node1: > 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container > 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service > node2: > 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service > 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1138) Revise configuration options of ssl-context in wildfly-config.xml

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1138?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1138: ------------------------------ Description: Comparing subsystem configuration options of client-ssl-context to wildfly-config.xml I am missing these attributes: * client-ssl-context ** use-cipher-suites-order ** maximum-session-cache-size ** session-timeout * key-managers/trust-managers: ** algorithm (is IBM - IBMX509 handled properly? e.g. *ManagerFactory.getDefaultAlgorithm() is called internally) * trust-manager ** certificate-revocation-list * key-managers ** key-password was: Comparing subsystem configuration options of client-ssl-context to wildfly-config.xml I am missing these attributes: * client-ssl-context ** use-cipher-suites-order ** maximum-session-cache-size ** session-timeout * key-managers/trust-managers: ** algorithm (is IBM - IBMX509 handled properly? e.g. *ManagerFactory.getDefaultAlgorithm() is called internally) * trust-manager ** certificate-revocation-list > Revise configuration options of ssl-context in wildfly-config.xml > ----------------------------------------------------------------- > > Key: ELY-1138 > URL: https://issues.jboss.org/browse/ELY-1138 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > > Comparing subsystem configuration options of client-ssl-context to wildfly-config.xml I am missing these attributes: > * client-ssl-context > ** use-cipher-suites-order > ** maximum-session-cache-size > ** session-timeout > * key-managers/trust-managers: > ** algorithm (is IBM - IBMX509 handled properly? e.g. *ManagerFactory.getDefaultAlgorithm() is called internally) > * trust-manager > ** certificate-revocation-list > * key-managers > ** key-password -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1138) Revise configuration options of ssl-context in wildfly-config.xml

by Martin Choma (JIRA)

Martin Choma created ELY-1138: --------------------------------- Summary: Revise configuration options of ssl-context in wildfly-config.xml Key: ELY-1138 URL: https://issues.jboss.org/browse/ELY-1138 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Critical Comparing subsystem configuration options of client-ssl-context to wildfly-config.xml I am missing these attributes: * client-ssl-context ** use-cipher-suites-order ** maximum-session-cache-size ** session-timeout * key-managers/trust-managers: ** algorithm (is IBM - IBMX509 handled properly? e.g. *ManagerFactory.getDefaultAlgorithm() is called internally) * trust-manager ** certificate-revocation-list -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8459) @TransactionAttribute should not be inherited per EJB 3.2 spec

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8459?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-8459: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1442955 Bugzilla Update: Perform > @TransactionAttribute should not be inherited per EJB 3.2 spec > --------------------------------------------------------------- > > Key: WFLY-8459 > URL: https://issues.jboss.org/browse/WFLY-8459 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: JBoss EA P7.0.x > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 11.0.0.Beta1 > > > It appears that JBoss EAP behaves as the *@TransactionAttribute* attribute was inherited. > For example if I have a bean A that > {noformat} > @Stateless > @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) > public class ABean extends Base{ > > public void foo(){ . . .} > } > {noformat} > and a supper class > {noformat} > @TransactionAttribute(TransactionAttributeType.SUPPORTS) > public class Base { > > @TransactionAttribute(TransactionAttributeType.NEVER) > public void foo(){ . . } > public void bar(){ . . .} > } > {noformat} > and if I call each method > {noformat} > beanA.bar(); > beanA.foo(); > {noformat} > I would expect to see *bar()* without an active transaction and *foo()* with an active transaction > but what I see is that both method have no active transaction. This seems like spec violation since the *@TransactionAttribute* are not supposed to be inherited. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1115: ---------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/791, https://github.com/wildfly-security/wildfly-elytron/pull/799 (was: https://github.com/wildfly-security/wildfly-elytron/pull/791) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina reopened ELY-1115: ----------------------------- > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > Fix For: 1.1.0.Beta41 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 May 2017