May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-2365: ------------------------------------------ [~dvilkola] I think it is safe to say no further action is needed at this time? > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Ondrej Lukas > Assignee: Diana Vilkolakova > Priority: Major > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2441) Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-2441?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-2441. -------------------------------------- Resolution: Out of Date > Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper > ------------------------------------------------------------------------------------ > > Key: WFCORE-2441 > URL: https://issues.jboss.org/browse/WFCORE-2441 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Ilia Vassilev > Priority: Major > Labels: user_experience > > There are inconsistencies between DMR and XSD representation of {{constant-permission-mapper}}. > According to XSD {{permission}} must occur at least one times in {{constant-permission-mapper}}. According to DMR it is {{"nillable" => true}}. This should be unified. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-4302: ------------------------------------------ [~dvilkola] Does this relate to your recent changes? > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Martin Mazanek > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12095?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-12095: ----------------------------------------- This is something to revisit after WFLY-1598 > Use HTTPS and only HTTPS for management interfaces in default configuration > --------------------------------------------------------------------------- > > Key: WFLY-12095 > URL: https://issues.jboss.org/browse/WFLY-12095 > Project: WildFly > Issue Type: Enhancement > Components: Management, Security > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Priority: Major > > Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration. > Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it). > Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11957) Support Group Managed Service Accounts (gMSA) - extend LDAP feature

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11957?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-11957: --------------------------------------- Assignee: (was: Darran Lofthouse) > Support Group Managed Service Accounts (gMSA) - extend LDAP feature > ------------------------------------------------------------------- > > Key: WFLY-11957 > URL: https://issues.jboss.org/browse/WFLY-11957 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Craig Carpenter > Priority: Major > > The introduction of gMSA in the enterprise is generating a need for support of this type of LDAP account where the user id is available but not the password. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12095) Use HTTPS and only HTTPS for management interfaces in default configuration

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12095?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-12095: --------------------------------------- Assignee: (was: Darran Lofthouse) > Use HTTPS and only HTTPS for management interfaces in default configuration > --------------------------------------------------------------------------- > > Key: WFLY-12095 > URL: https://issues.jboss.org/browse/WFLY-12095 > Project: WildFly > Issue Type: Enhancement > Components: Management, Security > Affects Versions: 16.0.0.Final > Reporter: Jan Stourac > Priority: Major > > Current default configuration of WildFly uses plaintext HTTP for management interfaces that are used for web-console access. Even though, that it is possible to switch to HTTPS after login to web-console, I believe we should incorporate HTTPS and only HTTPS configuration of management interfaces in our default WildFly configuration. > Note that there is digest-auth used for web-console login, thus password is not sent in a plain-text over the network, although there is still possibility of MITM attack, as such one can see what management operations are performed (actual request payload is binary, although I presume that it is easy to decode when one knows how to do it). > Yes, I understand that by default, there will be just a self-signed certificate generated for server on first HTTPS request, but I believe it is still an improvement. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4483) Add support for missing MP-JWT requirements

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4483?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4483: ---------------------------------------- Assignee: Martin Mazanek > Add support for missing MP-JWT requirements > ------------------------------------------- > > Key: WFCORE-4483 > URL: https://issues.jboss.org/browse/WFCORE-4483 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Martin Mazanek > Priority: Major > Labels: EAP-CD18 > Fix For: 10.0.0.Beta1 > > > There are two main things that are currently missing: > * Support for injection of the currently authenticated caller as a {{JsonWebToken}} > * The {{java.security.Principal}} returned from {{javax.ws.rs.core.SecurityContext.getUserPrincipal()}} must be an instance of {{org.eclipse.microprofile.jwt.JsonWebToken}} > More details can be found [here|https://www.eclipse.org/community/eclipse_newsletter/2017/september/...]. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-629: ------------------------------------ Fix Version/s: 10.0.0.Beta1 (was: 11.0.0.Beta1) > Enabled automatic encryption of passwords stored in configuration > ----------------------------------------------------------------- > > Key: WFCORE-629 > URL: https://issues.jboss.org/browse/WFCORE-629 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Environment: Wildfly 9 > Reporter: Jason Shepherd > Assignee: Darran Lofthouse > Priority: Major > Fix For: 10.0.0.Beta1 > > > Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration. > It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-11007: --------------------------------------- Assignee: (was: Stuart Douglas) > Using OpenShift generated certificates and client auth cause TLS errors > ----------------------------------------------------------------------- > > Key: WFLY-11007 > URL: https://issues.jboss.org/browse/WFLY-11007 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 13.0.0.Final > Reporter: Sebastian Laskawiec > Priority: Major > > h2. Summary > It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT: fatal, record_overflow}} message. > h2. Explanation > I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. > I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful. > h2. Possible solution > Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too. > Links: > - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13 > - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88 > - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616 > - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-lo... > - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-key... > - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-lo... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11880) Add a SASL mechanism reference to the documentation

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11880?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11880: ------------------------------------ Fix Version/s: (was: 17.0.0.Final) > Add a SASL mechanism reference to the documentation > --------------------------------------------------- > > Key: WFLY-11880 > URL: https://issues.jboss.org/browse/WFLY-11880 > Project: WildFly > Issue Type: Task > Components: Documentation, Security > Reporter: Darran Lofthouse > Priority: Major > > A mechanism by mechanism listing, describing the mech, any features / requirements of the mech and any properties or other configuration affecting the mech. > This will need to cover both the client and server perspectives. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2019