May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8772) Deployments referencing outbound connection with authentication context always use Elytron default-authentication-context

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8772?page=com.atlassian.jira.plugin.... ] Farah Juma moved JBEAP-10907 to WFLY-8772: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8772 (was: JBEAP-10907) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Remoting Security (was: Remoting) (was: Security) Affects Version/s: (was: 7.1.0.DR17) > Deployments referencing outbound connection with authentication context always use Elytron default-authentication-context > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8772 > URL: https://issues.jboss.org/browse/WFLY-8772 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security > Reporter: Farah Juma > Assignee: David Lloyd > Priority: Blocker > Labels: eap7.1-rfe-blocker, eap7.1-rfe-failure, eap71_beta_candidate > > Analysis document for EAP7-551 states the following: > {quote}This RFE is to add a reference to the new authentication-context capability to the remote-outbound-connection resource and make use of it satisfy the security requirements for the outbound connections being established. > The AuthenticationContext will be used to access both information required for authentication and also for any SSLContext required for the connection. > A newly referenced authentication-context will be used to provide all security configuration for outbound connections.{quote} > However, currently the remoting outbound connections will only use Elytron default authentication context and ignore authentication context defined in remoting outbound connection resource: > * If no default authentication context is defined in Elytron subsystem but remote outbound connection has defined one, no authentication context is associated with remote outbound connection. > * If the default authentication context is defined in Elytron subsystem but no authentication context is defined in remote outbound connection, remoting assumes that outbound connection uses legacy security. > * If the default authentication context is defined in Elytron subsystem and different authentication context is defined in remote outbound connection, the remote outbound connection will use the Elytron subsystem default none the less. > * The authentication context defined in outbound remote connection will only work if it is the same as default authentication context in Elytron subsystem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8771) Encryption protocols are registered with their full class name

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8771?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-8771. ------------------------------ Resolution: Won't Fix This is intentional. This is how legacy encrypt protocols are supported. This in no way breaks user scripts. > Encryption protocols are registered with their full class name > -------------------------------------------------------------- > > Key: WFLY-8771 > URL: https://issues.jboss.org/browse/WFLY-8771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Minor > > With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at > {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} > as opposed to (DR17) > {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} > This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. > If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. > Present on current master: aaab23b6f1c00102b6bafd4f028aa1e1d59b8b84 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8771) Encryption protocols are registered with their full class name

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8771?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-8771: -------------------------------- Description: With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} as opposed to (DR17) {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. Present on current master: aaab23b6f1c00102b6bafd4f028aa1e1d59b8b84 was: With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} as opposed to (DR17) {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. > Encryption protocols are registered with their full class name > -------------------------------------------------------------- > > Key: WFLY-8771 > URL: https://issues.jboss.org/browse/WFLY-8771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Minor > > With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at > {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} > as opposed to (DR17) > {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} > This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. > If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. > Present on current master: aaab23b6f1c00102b6bafd4f028aa1e1d59b8b84 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8771) Encryption protocols are registered with their full class name

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8771?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-8771: -------------------------------- Affects Version/s: (was: 11.0.0.Beta1) > Encryption protocols are registered with their full class name > -------------------------------------------------------------- > > Key: WFLY-8771 > URL: https://issues.jboss.org/browse/WFLY-8771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Minor > > With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at > {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} > as opposed to (DR17) > {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} > This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. > If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8771) Encryption protocols are registered with their full class name

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8771?page=com.atlassian.jira.plugin.... ] Richard Janík moved JBEAP-10905 to WFLY-8771: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8771 (was: JBEAP-10905) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) > Encryption protocols are registered with their full class name > -------------------------------------------------------------- > > Key: WFLY-8771 > URL: https://issues.jboss.org/browse/WFLY-8771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Minor > > With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at > {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} > as opposed to (DR17) > {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} > This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. > If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8771) Encryption protocols are registered with their full class name

by Richard Janík (JIRA)

[ https://issues.jboss.org/browse/WFLY-8771?page=com.atlassian.jira.plugin.... ] Richard Janík updated WFLY-8771: -------------------------------- Affects Version/s: 11.0.0.Beta1 > Encryption protocols are registered with their full class name > -------------------------------------------------------------- > > Key: WFLY-8771 > URL: https://issues.jboss.org/browse/WFLY-8771 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Minor > > With DR18 when adding an encryption protocol, e.g. SYM_ENCRYPT, the resource is then available at > {{/subsystem=jgroups/stack=udp/protocol=org.jgroups.protocols.ASYM_ENCRYPT}} > as opposed to (DR17) > {{/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT}} > This requires at least a change in docs and may break user scripts. I think it would be better if we used the old resource names. > If this is intentional, let's discuss. If there's a good reason for it, I'll respec this as a documentation issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2806: ---------------------------------------- Assignee: (was: Brad Maxwell) > Global domain config for unique GC log file name and path > --------------------------------------------------------- > > Key: WFCORE-2806 > URL: https://issues.jboss.org/browse/WFCORE-2806 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Aaron Ogburn > Labels: domain-mode > > Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members: > {code} > <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/> > {code} > But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is: > {code} > <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/> > {code} > But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2806: ------------------------------------- Component/s: Domain Management > Global domain config for unique GC log file name and path > --------------------------------------------------------- > > Key: WFCORE-2806 > URL: https://issues.jboss.org/browse/WFCORE-2806 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Aaron Ogburn > Labels: domain-mode > > Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members: > {code} > <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/> > {code} > But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is: > {code} > <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/> > {code} > But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2806) Global domain config for unique GC log file name and path

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2806?page=com.atlassian.jira.plugi... ] Brian Stansberry moved PRODMGT-1744 to WFCORE-2806: --------------------------------------------------- Project: WildFly Core (was: Product Management) Key: WFCORE-2806 (was: PRODMGT-1744) Workflow: GIT Pull Request workflow (was: JBoss Platforms RFE Workflow v2) Affects Version/s: (was: 7) > Global domain config for unique GC log file name and path > --------------------------------------------------------- > > Key: WFCORE-2806 > URL: https://issues.jboss.org/browse/WFCORE-2806 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Aaron Ogburn > Assignee: Brad Maxwell > Labels: domain-mode > > Customers often try to do something like the following in their server group for domain mode to easily get a unique gc log path for all server group members: > {code} > <option value="-Xloggc:${jboss.server.log.dir}/gc.log"/> > {code} > But jboss.server.log.dir can't be resolved at that point so it fails. The next best thing that can be done is: > {code} > <option value="-Xloggc:${jboss.domain.servers.dir}/server-name/log/gc.log"/> > {code} > But then that has to be set for each server. It'd help if domain mode had some way of easily setting a gc.log path in a server-group level or higher that could be set once and result in unique gc log paths for all servers in the server-group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-783) alias-filter from Elytron key-store does not work for non-lower-case alias with JKS

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-783?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-783: -------------------------------------- We need to double check in our filtering if we make an assumption that it is case sensitive and convert to lower case or something like that before comparing. > alias-filter from Elytron key-store does not work for non-lower-case alias with JKS > ----------------------------------------------------------------------------------- > > Key: ELY-783 > URL: https://issues.jboss.org/browse/ELY-783 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Yeray Borges > > In case when {{alias-filter}} attribute from Elytron {{key-store}} references non-lower-case alias (e.g. elytronAppServer) then SSL is not working. In case when this alias is set to lower-case in alias-filter (e.g. elytronappserver), then SSL works correctly. > It seems JKS always transforms aliases to lower-case (even if they are created with some upper-case characters). However legacy security solution was able to use alias filter with non-lower-case characters to assign key from JKS keystore (probably through some internal {{.toLowerCase()}}). > In case it is intended to do not use alias-filter with some upper-case for JKS then this issue can be changed to documentation issue. This is different behavior than was provided by legacy solution. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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