December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5815) Read resource of deployment with faulty datasource fails

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5815?page=com.atlassian.jira.plugin.... ] Tomaz Cerar moved WFCORE-1196 to WFLY-5815: ------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-5815 (was: WFCORE-1196) Component/s: Domain Management (was: Domain Management) Affects Version/s: (was: 2.0.4.Final) > Read resource of deployment with faulty datasource fails > -------------------------------------------------------- > > Key: WFLY-5815 > URL: https://issues.jboss.org/browse/WFLY-5815 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Harald Pehl > Assignee: Tomaz Cerar > > For the setup see HAL-1006. Reading the deployments of a server which contains a deployment with a faulty datasource, yields an undefined result: > {code} > /host=master/server=server-one:read-children-resources(child-type=deployment,recursive=true,include-runtime=true) > { > "outcome" => "success", > "result" => undefined, > "failure-description" => undefined > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-107) Add ability for security domains to create SSLContext directly from config

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-107?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-107: --------------------------------- Does {{org.wildfly.security.ssl.ServerSSLContextBuilder}} adequately cover this? > Add ability for security domains to create SSLContext directly from config > -------------------------------------------------------------------------- > > Key: ELY-107 > URL: https://issues.jboss.org/browse/ELY-107 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-29) Common Use Cases

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-29?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-29: -------------------------------- Maybe this could be resolved now? > Common Use Cases > ---------------- > > Key: ELY-29 > URL: https://issues.jboss.org/browse/ELY-29 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR1 > > > The API/SPI of Elytron is based around numerous discussions on the scenarios we need to support in an application server environment - this is a parent task to start adding some test cases that cover these scenarios. > Any subsequent API evolution has to take into account the scenarios we must - this will also be key to identifying backwards compatibility going forward. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5327) Support simple cache optimization in Infinispan subsystem

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5327?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5327: ------------------------------- Issue Type: Enhancement (was: Feature Request) > Support simple cache optimization in Infinispan subsystem > --------------------------------------------------------- > > Key: WFLY-5327 > URL: https://issues.jboss.org/browse/WFLY-5327 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.0.0.Beta2 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 10.0.0.CR5 > > > Infinispan 8.0.1.Final includes a new simple cache, that is effectively a local cache without an interceptor stack, and thus without support for transactions, persistence, etc. > Unfortunately, the configuration of such a cache in Infinispan is sloppy. A simple cache is configured by a single boolean attribute, which of course means that all kinds of invalid configuration combinations are possible. Ideally, a simple cache configuration should only expose relevant configuration aspects. I propose we create a new cache type like so: > {code:xml} > <simple-cache name="..."> > <eviction .../> > <expiration .../> > </simple-cache> > {code} > The fact that this doesn't translate into a designated cache mode is irrelevant. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-129) Choose SASL mechanisms based on better criteria

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-129?page=com.atlassian.jira.plugin.sy... ] David Lloyd resolved ELY-129. ----------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.CR1) Assignee: David Lloyd Resolution: Done This is resolved as a result of mechanism configuration. > Choose SASL mechanisms based on better criteria > ----------------------------------------------- > > Key: ELY-129 > URL: https://issues.jboss.org/browse/ELY-129 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta3 > > > SASL mechanism selection is based on properties right now, that specify only a few very limited criteria. > We should provide a better selection mechanism that allows selection based on the following criteria: > * Specify requirements of the mechanism itself > ** Algorithm usage > ** Key length (where applicable) > ** Parameters similar to existing Sasl ones, like: > *** QOP > *** Forward secrecy > *** Plaintext > *** Active attack susceptibility > *** etc. > * Specify requirements around the mechanism's circumstance > ** Restrict by enclosing channel security > *** Require TLS cipher suite parameters (using existing database parameters) > *** Require channel binding > In the end the client or server user should be able specify SASL mechanism usage using expressions that can express things like: > * Use PLAIN only if TLS is in use with AES encryption > * Use EXTERNAL only if TLS is in use > * Use no SASL mechanisms employing weak hash algorithms (MD5 and worse) > * Use only SASL mechanisms employing SHA-256 > * Use only SASL mechanisms that provide channel binding and require TLS > * Use only ANONYMOUS -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-59) Custom properties within mechanism selection

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-59?page=com.atlassian.jira.plugin.sys... ] David Lloyd resolved ELY-59. ---------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.CR1) Resolution: Done This should be considered resolved, due to the mechanism configuration changes. > Custom properties within mechanism selection > -------------------------------------------- > > Key: ELY-59 > URL: https://issues.jboss.org/browse/ELY-59 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta3 > > > Some custom properties should maybe impact on mechanism selection e.g. wildfly.sasl.channel-binding.mode if set to required GSSAPI should be excluded as it does not support channel binding. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-85) Support GSS-Proxy

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-85: -------------------------------- It might be necessary to create or reuse an existing JNI GSS bridge for various GSSAPI implementations in order to support this, if the JDK code does not provide this functionality. > Support GSS-Proxy > ----------------- > > Key: ELY-85 > URL: https://issues.jboss.org/browse/ELY-85 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR1 > > > GSS Proxy is something we should consider being able to support when running on an OS that supports it: - > https://fedorahosted.org/gss-proxy/ > The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-66) SASL Proxy

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-66?page=com.atlassian.jira.plugin.sys... ] David Lloyd resolved ELY-66. ---------------------------- Resolution: Rejected This does not appear to be a viable mechanism for remote security domain authentication: * It interferes with channel binding * There is no way to acquire an identity as a result of proxied authentication * Things like SASL server name do not align > SASL Proxy > ---------- > > Key: ELY-66 > URL: https://issues.jboss.org/browse/ELY-66 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-385) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA"

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-385?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-385: --------------------------------- Once ELY-389 is merged it should become very clear what is happening here. > ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" > -------------------------------------------------- > > Key: ELY-385 > URL: https://issues.jboss.org/browse/ELY-385 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Optional > > 05:48:13 [33m05:48:13,801 WARN [org.wildfly.security] (MSC service thread 1-2) ELY01077: Invalid alias "TLS_RSA_WITH_DES_CBC_SHA" for missing mechanism database entry "TLS_RSA_FIPS_WITH_DES_CBC_SHA" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-384) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-384?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-384: --------------------------------- Once ELY-389 is merged it should become very clear what is happening here. > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: ELY-384 > URL: https://issues.jboss.org/browse/ELY-384 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 December 2015