May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1152) Rework security Provider behaviour

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1152?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1152. ----------------------------------- Resolution: Done > Rework security Provider behaviour > ---------------------------------- > > Key: ELY-1152 > URL: https://issues.jboss.org/browse/ELY-1152 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta43 > > > Everything that makes use of providers should be using a Supplier<Provider[]> which exists as a result of parsing the configuration. > Our default behaviour should likely be a combination of globally defined providers, and service loader discovered providers. Config then is more likely to be about disabling one or both rather than enabling. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.

by Hynek Švábek (JIRA)

Hynek Švábek created ELY-1168: --------------------------------- Summary: Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. Key: ELY-1168 URL: https://issues.jboss.org/browse/ELY-1168 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek Švábek Assignee: Darran Lofthouse Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. It seems to be little confusing. I prefer error message rather than success. Reason why it works now is because as a value is used default value for entry-type. *How to reproduce* {code} java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n Alias "secret_alias" has been successfully stored {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1168) Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1168?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1168: ------------------------------ Component/s: Credential Store > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > ---------------------------------------------------------------------------------------------------------- > > Key: ELY-1168 > URL: https://issues.jboss.org/browse/ELY-1168 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > Wildfly Elytron Tool, credential-store command "add" option with --entry-type without argument value pass. > It seems to be little confusing. I prefer error message rather than success. > Reason why it works now is because as a value is used default value for entry-type. > *How to reproduce* > {code} > java -jar ./bin/wildfly-elytron-tool.jar credential-store --add secret_alias --create -l store123.jceks --password pass123 -x test -n > Alias "secret_alias" has been successfully stored > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8800) JBoss CLI run with IBM JDK is not able to use secure connection when server uses Elytron ssl-context

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8800?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-8800: ------------------------------- Description: In case SSL through Elytron ssl-context is configured for management interface then JBoss CLI is not able to authenticate when it is run with IBM JDK. It works correctly when * Legacy SSL is used instead of Elytron ssl-context * or non-IBM JDK is used for JBoss CLI * or only authentication without SSL is used It fails for http-interface as well as native-interface. When different client is used for connection to management interface (I tried it with ModelControllerClient) then authentication and SSL works correctly. For http-interface following output of CLI is print: {code} Failed to connect to the controller: The controller is not available at localhost:9993: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: java.nio.channels.ClosedChannelException {code} For native-interface following output of CLI is print: {code} Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9999 {code} was: In case SSL through Elytron ssl-context is configured for management interface then JBoss CLI is not able to authenticate when it is run with IBM JDK. It works correctly when * Legacy SSL is used instead of Elytron ssl-context * or non-IBM JDK is used for JBoss CLI * or only authentication without SSL is used It fails for http-interface as well as native-interface. When different client is used for connection to management interface (I tried it with ModelControllerClient) then authentication and SSL works correctly. For http-interface following output of CLI is print: {code} Failed to connect to the controller: The controller is not available at localhost:9993: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: java.nio.channels.ClosedChannelException {code} For native-interface following output of CLI is print: {code} Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9999 {code} This issues is reported in EAP 7.1.0.DR18 because previous versions have not been able to start application server with IBM JDK. We request blocker since IBM JDK is supported and missing ability to connect to application server with secured connection blocks RFE EAP7-628. > JBoss CLI run with IBM JDK is not able to use secure connection when server uses Elytron ssl-context > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-8800 > URL: https://issues.jboss.org/browse/WFLY-8800 > Project: WildFly > Issue Type: Bug > Components: CLI, Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > > In case SSL through Elytron ssl-context is configured for management interface then JBoss CLI is not able to authenticate when it is run with IBM JDK. > It works correctly when > * Legacy SSL is used instead of Elytron ssl-context > * or non-IBM JDK is used for JBoss CLI > * or only authentication without SSL is used > It fails for http-interface as well as native-interface. > When different client is used for connection to management interface (I tried it with ModelControllerClient) then authentication and SSL works correctly. > For http-interface following output of CLI is print: > {code} > Failed to connect to the controller: The controller is not available at localhost:9993: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: java.nio.channels.ClosedChannelException > {code} > For native-interface following output of CLI is print: > {code} > Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9999 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8800) JBoss CLI run with IBM JDK is not able to use secure connection when server uses Elytron ssl-context

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-8800: ---------------------------------- Summary: JBoss CLI run with IBM JDK is not able to use secure connection when server uses Elytron ssl-context Key: WFLY-8800 URL: https://issues.jboss.org/browse/WFLY-8800 Project: WildFly Issue Type: Bug Components: CLI, Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Blocker In case SSL through Elytron ssl-context is configured for management interface then JBoss CLI is not able to authenticate when it is run with IBM JDK. It works correctly when * Legacy SSL is used instead of Elytron ssl-context * or non-IBM JDK is used for JBoss CLI * or only authentication without SSL is used It fails for http-interface as well as native-interface. When different client is used for connection to management interface (I tried it with ModelControllerClient) then authentication and SSL works correctly. For http-interface following output of CLI is print: {code} Failed to connect to the controller: The controller is not available at localhost:9993: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: WFLYPRT0053: Could not connect to remote+https://localhost:9993. The connection failed: java.nio.channels.ClosedChannelException {code} For native-interface following output of CLI is print: {code} Failed to connect to the controller: Unable to negotiate SSL connection with controller at localhost:9999 {code} This issues is reported in EAP 7.1.0.DR18 because previous versions have not been able to start application server with IBM JDK. We request blocker since IBM JDK is supported and missing ability to connect to application server with secured connection blocks RFE EAP7-628. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1167) WildFly Elytron Tool, Credential-store command has to have way how to set security provider for custom credential store implementation.

by Hynek Švábek (JIRA)

Hynek Švábek created ELY-1167: --------------------------------- Summary: WildFly Elytron Tool, Credential-store command has to have way how to set security provider for custom credential store implementation. Key: ELY-1167 URL: https://issues.jboss.org/browse/ELY-1167 Project: WildFly Elytron Issue Type: Bug Reporter: Hynek Švábek Assignee: Darran Lofthouse Priority: Critical Wildfly Elytron Tool has not a way how to set own security provider with custom credential store implementation when we want to work with credential-store command. Now you can only set it through java.security settings for JVM but as is mentioned here https://issues.jboss.org/browse/JBEAP-9310?focusedCommentId=13375779&page... it is not supported way. There must be some other approach how to set it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1167) WildFly Elytron Tool, Credential-store command has to have way how to set security provider for custom credential store implementation.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1167?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1167: ------------------------------ Component/s: Credential Store > WildFly Elytron Tool, Credential-store command has to have way how to set security provider for custom credential store implementation. > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1167 > URL: https://issues.jboss.org/browse/ELY-1167 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Critical > > Wildfly Elytron Tool has not a way how to set own security provider with custom credential store implementation when we want to work with credential-store command. > Now you can only set it through java.security settings for JVM but as is mentioned here https://issues.jboss.org/browse/JBEAP-9310?focusedCommentId=13375779&page... > it is not supported way. > There must be some other approach how to set it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-389: ----------------------------------------- Analysis doc for this is at https://developer.jboss.org/docs/DOC-55978 > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFCORE-389 > URL: https://issues.jboss.org/browse/WFCORE-389 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP, domain-mode > Fix For: 3.0.0.CR1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2824) JDK8HackAlpnProvider doesn't work for client when used with elytron ssl-context

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2824?page=com.atlassian.jira.plugi... ] Stuart Douglas moved JBEAP-10977 to WFCORE-2824: ------------------------------------------------ Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2824 (was: JBEAP-10977) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) (was: Web (Undertow)) Affects Version/s: (was: 7.1.0.DR18) > JDK8HackAlpnProvider doesn't work for client when used with elytron ssl-context > ------------------------------------------------------------------------------- > > Key: WFCORE-2824 > URL: https://issues.jboss.org/browse/WFCORE-2824 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > When I setup undertow as proxy and one server behind it, even when I define that there should be used HTTP/2 (possible with mod_cluster filter) for proxy to worker communication it isn't used for default undertow ALPN JDK8 implementation. > It is possible to make it work with openssl ALPN provider but not with the default one, which I believe it should work with as well. > *EDIT:* doesn't work only with elytron based ssl-context. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-389: ------------------------------------ Fix Version/s: 3.0.0.CR1 (was: 4.0.0.Beta1) > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFCORE-389 > URL: https://issues.jboss.org/browse/WFCORE-389 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP, domain-mode > Fix For: 3.0.0.CR1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- 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