July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9151) CLIENT_CERT without users certificates database

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-9151?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-9151: ----------------------------- Fix Version/s: 12.0.0.Alpha1 > CLIENT_CERT without users certificates database > ----------------------------------------------- > > Key: WFLY-9151 > URL: https://issues.jboss.org/browse/WFLY-9151 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Fix For: 12.0.0.Alpha1 > > > CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them. > Analysis document: > https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9151) CLIENT_CERT without users certificates database

by Jan Kalina (JIRA)

Jan Kalina created WFLY-9151: -------------------------------- Summary: CLIENT_CERT without users certificates database Key: WFLY-9151 URL: https://issues.jboss.org/browse/WFLY-9151 Project: WildFly Issue Type: Feature Request Components: Security Affects Versions: 11.0.0.Alpha1 Reporter: Jan Kalina Assignee: Jan Kalina CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them. Analysis document: https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3121) Elytron is registering resource /core-service=management/access=identity on a HostController

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3121?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3121: ------------------------------------- Fix Version/s: 3.0.0.CR1 (was: 3.0.0.Beta30) > Elytron is registering resource /core-service=management/access=identity on a HostController > -------------------------------------------------------------------------------------------- > > Key: WFCORE-3121 > URL: https://issues.jboss.org/browse/WFCORE-3121 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 3.0.0.CR1 > > > The Elytron integration added a resource registration for /core-service=management/access=identity on an HC. It should only be registered at /host=*/core-service=management/access=identity > The domain-wide /core-service=management resource MUST NOT HAVE CHILDREN REGISTERED other than access-authorization. It is not the place to configure HC-specific behavior. > I see use of this resource in enable-elytron.cli scripts used to configure the testsuite. At least in the one in WF full's testsuite/shared; I'm guessing elsewhere too. That must be changed. > If use of this domain-wide resource has ended up in any docs those must be corrected. > [~dlofthouse] FYI. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2100: ------------------------------------- Fix Version/s: 3.0.0.CR1 (was: 3.0.0.Beta30) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1683) ExcelParse can re-write files

by James Livingston (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1683?page=com.atlassian.jira.plugi... ] James Livingston updated DROOLS-1683: ------------------------------------- Description: ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in read-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk. Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently. It should use the three argument form of WorkbookFactory.create() and pass the read-only flag was: ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in rewad-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk. Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently. It should use the three argument form of WorkbookFactory.create() and pass the read-only flag > ExcelParse can re-write files > ----------------------------- > > Key: DROOLS-1683 > URL: https://issues.jboss.org/browse/DROOLS-1683 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.0.0.Final > Reporter: James Livingston > Assignee: Mario Fusco > > ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in read-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk. > Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently. > It should use the three argument form of WorkbookFactory.create() and pass the read-only flag -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1683) ExcelParse can re-write files

by James Livingston (JIRA)

James Livingston created DROOLS-1683: ---------------------------------------- Summary: ExcelParse can re-write files Key: DROOLS-1683 URL: https://issues.jboss.org/browse/DROOLS-1683 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 7.0.0.Final Reporter: James Livingston Assignee: Mario Fusco ExcelParser.open(File) uses the single argument WorkbookFactory.create() call, which opens the file in rewad-write mode, so when parseWorkbook() calls close on it, it will save the workbook to disk. Usually the resulting file is the same, however it may be binary-different but equivalent(causing git conflicts). Being read-only does not cause an error since the exceptions are swallowed silently. It should use the three argument form of WorkbookFactory.create() and pass the read-only flag -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9148) Clustering subsystems use of deprecated XML writer registration

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-9148?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-9148: ------------------------------- Summary: Clustering subsystems use of deprecated XML writer registration (was: Clustering subsystem use of deprecated XML writer registration) > Clustering subsystems use of deprecated XML writer registration > --------------------------------------------------------------- > > Key: WFLY-9148 > URL: https://issues.jboss.org/browse/WFLY-9148 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle TERM cleanly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3073: ---------------------------------------- Component/s: Domain Management (was: Server) Assignee: Brian Stansberry (was: Jason Greene) > Handle TERM cleanly > ------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle TERM cleanly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3073: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 > Handle TERM cleanly > ------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha1 > > > The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3123) ManagementXml is parsing and marshaling the full set of resource regardless of document type

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3123: ---------------------------------------- Summary: ManagementXml is parsing and marshaling the full set of resource regardless of document type Key: WFCORE-3123 URL: https://issues.jboss.org/browse/WFCORE-3123 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry The set of legal elements in the "management" part of a config file is different for domain.xml vs host and standalone.xml. For domain.xml it's meant to be limited to rbac. But ManagementXml does not reflect that, making it easier to introduce mistakes like WFCORE-3121. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 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 July 2017