[JBoss JIRA] (WFLY-9152) CLIENT_CERT without users certificates database
by Jan Kalina (JIRA)
Jan Kalina created WFLY-9152:
--------------------------------
Summary: CLIENT_CERT without users certificates database
Key: WFLY-9152
URL: https://issues.jboss.org/browse/WFLY-9152
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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months
[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, 5 months