[Red Hat JIRA] (WFCORE-4970) Changing the JVM settings at host level does not put the servers in restart-required
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4970?page=com.atlassian.jira.plug... ]
Brian Stansberry commented on WFCORE-4970:
------------------------------------------
Something to think about for this is AbstractAttributeDefinitionBuilder.addArbitraryDescriptor. This can be used to attach unusual metadata to an attribute so it can be read by management code, for use when the general-purpose metadata does not cleanly fit a use case.
> Changing the JVM settings at host level does not put the servers in restart-required
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-4970
> URL: https://issues.redhat.com/browse/WFCORE-4970
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta2
> Reporter: Yeray Borges Santana
> Assignee: Parul Sharma
> Priority: Major
>
> Operations like the following one should put the servers in restart required to indicate the user changes will be applied after restarting the servers:
> {noformat}
> [domain@localhost:9990 /] /host=master/jvm=default:write-attribute(name=heap-size, value=256m)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ]
Farah Juma commented on WFLY-14420:
-----------------------------------
[~pferraro] Since you had helped with the updates to \{{ApplicationSecurityDomainSingleSignOnDefinition}} for WFLY-12218, would you be able to help us with this one?
> Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14420
> URL: https://issues.redhat.com/browse/WFLY-14420
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Farah Juma
> Priority: Major
>
> When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
>
> {code:xml}
> ### Pre-requisite steps
> /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
> /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
> /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
> ### Enable single-sign-on
> /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
> # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
>
> This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
> As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFLY-14420:
------------------------------
Description:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:xml}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
was:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:xml}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
> Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14420
> URL: https://issues.redhat.com/browse/WFLY-14420
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Farah Juma
> Priority: Major
>
> When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
>
> {code:xml}
> ### Pre-requisite steps
> /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
> /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
> /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
> ### Enable single-sign-on
> /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
> # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
>
> This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
> As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFLY-14420:
------------------------------
Description:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:xml}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
was:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:java}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
> Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14420
> URL: https://issues.redhat.com/browse/WFLY-14420
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Farah Juma
> Priority: Major
>
> When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
>
> {code:xml}
> ### Pre-requisite steps
> /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
> /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
> /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
> ### Enable single-sign-on
> /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
> # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
>
> This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
>
> As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-14420?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFLY-14420:
------------------------------
Description:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:java}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
was:
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:java}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
> Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-14420
> URL: https://issues.redhat.com/browse/WFLY-14420
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Farah Juma
> Priority: Major
>
> When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
>
> {code:java}
> ### Pre-requisite steps
> /subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
> /subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
> /subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
> ### Enable single-sign-on
> /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
> # At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
>
> This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
>
> As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14420) Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
by Farah Juma (Jira)
Farah Juma created WFLY-14420:
---------------------------------
Summary: Automatic credential store update not triggered when enabling single-sign-on using a credential-reference
Key: WFLY-14420
URL: https://issues.redhat.com/browse/WFLY-14420
Project: WildFly
Issue Type: Bug
Components: Security, Web (Undertow)
Reporter: Farah Juma
When enabling {{single-sign-on}} with a {{credential-reference}} in the Undertow subsystem using the {{store}} and {{clear-text}} attributes, the automatic credential store update that should happen is never triggered. Looking closer, it appears that the appropriate model update takes place (e.g., the {{clear-text}} attribute is saved and removed from the model) but the actual runtime update to the credential store itself is never triggered. This issue can be reproduced using the following steps:
{code:java}
### Pre-requisite steps
/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)
/subsystem=undertow/application-security-domain=other:add(security-domain=ApplicationDomain)
/subsystem=elytron/key-store=myKS:add(path=keystore.jks, relative-to=jboss.server.config.dir, credential-reference={clear-text=secret}, type=JKS)
### Enable single-sign-on
/subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=myKS, key-alias=localhost, domain=localhost, credential-reference={store=myCredStore,alias=myNewAlias,clear-text=myNewPassword})
# At this point, the output of the above operation is supposed to indicate that a credential-store update took place and executing the read-aliases() operation on the credential-store is supposed to show 'myNewAlias'. However, this doesn't happen.{code}
This issue only affects credential store updates that take place when enabling {{single-sign-on}}. If the {{credential-reference.clear-text}} value is updated for an existing {{single-sign-on}} element using the {{write-attribute}} operation, the corresponding credential store update is successfully triggered.
As a quick sanity check, I tried testing credential store updates with some other resources from the clustering subsystems (e.g., I tried adding the jgroups AUTH protocol resource with {{key-credential-reference}} and {{shared-secret-reference}}) but the credential store update was successfully triggered for these when adding the resource. The main difference appears to be that {{CredentialReference.getCredentialSourceSupplier(...)}} is successfully triggered during the runtime phase in this case but it does not get triggered for the {{single-sign-on}} case. This method triggers the credential store update.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14418) Add tests to batch-jberet subsystem for attributes that allow expression
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-14418?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-14418:
------------------------------
Description:
The following attributes in batch-jberet subsystem allows expression:
restart-jobs-on-resume
thread-pool/max-threads
thread-factory/group-name
thread-factory/priority
thread-factory/thread-name-pattern
> Add tests to batch-jberet subsystem for attributes that allow expression
> ------------------------------------------------------------------------
>
> Key: WFLY-14418
> URL: https://issues.redhat.com/browse/WFLY-14418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> The following attributes in batch-jberet subsystem allows expression:
> restart-jobs-on-resume
> thread-pool/max-threads
> thread-factory/group-name
> thread-factory/priority
> thread-factory/thread-name-pattern
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months