[JBoss JIRA] (ELY-1932) Support for multiple security realms - Distributed Identities
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1932?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved ELY-1932.
-----------------------------
Resolution: Done
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: ELY-1932
> URL: https://issues.redhat.com/browse/ELY-1932
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Martin Mazánek
> Assignee: Martin Mazánek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 1.13.0.CR2
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (ELY-1932) Support for multiple security realms - Distributed Identities
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1932?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1932:
----------------------------
Fix Version/s: 1.13.0.CR2
> Support for multiple security realms - Distributed Identities
> -------------------------------------------------------------
>
> Key: ELY-1932
> URL: https://issues.redhat.com/browse/ELY-1932
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Martin Mazánek
> Assignee: Martin Mazánek
> Priority: Major
> Labels: CD17-Deferred, EAP-CD19, Previous_RFE
> Fix For: 1.13.0.CR2
>
>
> By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list.
> This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together.
> Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged.
> This RFE is not about fail over in the event of a realm being unavailable although it may be related.
> This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-13641:
--------------------------------------
[~jviebig] awesome, thanks!
I started debugging and I can see that inside {{ExternalBeanArchiveProcessor}} we already see ear/ejb.jar as a module dependency of the WAR which is why we start processing it.
We see it as [{{DependencySpec}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/deployment/processors/ExternalBeanArchiveProcessor.java#L168] which is a class from [jboss-modules|https://github.com/jboss-modules/jboss-modules/blob/1.x/src...] that allows some introspection.
Namely it has bunch of import/export filters and specifically the import filter _might_ be used to determine whether we want to process that dependency (because it differs based on how you specify that dependency in jboss-deployment-structure).
E.g. we should be able to test whether that filter accepts "META-INF" and skip processing if it doesn't. Although I am not sure if that's a proper way to solve this issue.
I will try to play with it a little more today/tomorrow and see if it breaks something else.
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13641
> URL: https://issues.redhat.com/browse/WFLY-13641
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 20.0.0.Final
> Reporter: Jens Viebig
> Assignee: Matěj Novotný
> Priority: Major
>
> When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class:
> WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml
> Seems VFS cannot get hold of the classes.
> The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13657) JGroups subsystem logs "version is missing in the configuration file" warning without a log code on deployment using JPA 2LC
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13657?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13657:
--------------------------------
Priority: Minor (was: Critical)
> JGroups subsystem logs "version is missing in the configuration file" warning without a log code on deployment using JPA 2LC
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13657
> URL: https://issues.redhat.com/browse/WFLY-13657
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 20.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
>
> This warning without a log code is logged upon deployment of application:
> {code}
> 13:06:16,312 WARNING [org.jgroups.conf.XmlConfigurator] (ServerService Thread Pool -- 101) version is missing in the configuration file
> {code}
> I can see this with several EAP Quickstarts, the exact list from CD20 is: batch-processing, bmt, cmt, greeter, hibernate, kitchensink, kitchensink-jsp, kitchensink-ml, managed-executor-service, spring-greeter, spring-kitchensink-basic, tasks-jsf, thread-racing
> Not sure if it's relevant, but I have noticed all the above mentioned QS use H2. None of the QS that don't use H2 has the warning logged.
> This can be reproduced with [WildFly 20 Final release|https://wildfly.org/downloads/] and [WildFly 20 Final QS|https://github.com/wildfly/quickstart/tree/20.0.0.Final] as well:
> 1. Start the server with {{$JBOSS_HOME/bin/standalone.sh}}
> 2. Deploy one of the above mentioned QS with {{mvn clean package wildfly:deploy}}
> This warning was not present in CD19 and earlier releases.
> The same warning was also logged on startup, which has been fixed with JBEAP-19734 and WFLY-13590.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13657) JGroups subsystem logs "version is missing in the configuration file" warning without a log code on deployment using JPA 2LC
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13657?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-19886 to WFLY-13657:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13657 (was: JBEAP-19886)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 20.0.1.Final
(was: 7.4.0.CD20-CR1)
> JGroups subsystem logs "version is missing in the configuration file" warning without a log code on deployment using JPA 2LC
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13657
> URL: https://issues.redhat.com/browse/WFLY-13657
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 20.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Critical
>
> This warning without a log code is logged upon deployment of application:
> {code}
> 13:06:16,312 WARNING [org.jgroups.conf.XmlConfigurator] (ServerService Thread Pool -- 101) version is missing in the configuration file
> {code}
> I can see this with several EAP Quickstarts, the exact list from CD20 is: batch-processing, bmt, cmt, greeter, hibernate, kitchensink, kitchensink-jsp, kitchensink-ml, managed-executor-service, spring-greeter, spring-kitchensink-basic, tasks-jsf, thread-racing
> Not sure if it's relevant, but I have noticed all the above mentioned QS use H2. None of the QS that don't use H2 has the warning logged.
> This can be reproduced with [WildFly 20 Final release|https://wildfly.org/downloads/] and [WildFly 20 Final QS|https://github.com/wildfly/quickstart/tree/20.0.0.Final] as well:
> 1. Start the server with {{$JBOSS_HOME/bin/standalone.sh}}
> 2. Deploy one of the above mentioned QS with {{mvn clean package wildfly:deploy}}
> This warning was not present in CD19 and earlier releases.
> The same warning was also logged on startup, which has been fixed with JBEAP-19734 and WFLY-13590.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5022) The /subsystem=elytron/policy=* can be simplified a lot further
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5022?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5022:
-------------------------------------
Description:
At the moment this resource is quite verbose but the tasks it performs are very simple.
{code:java}
[standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "elytron"),
("policy" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A definition that sets up a policy provider.",
"max-occurs" => 1,
"capabilities" => [{
"name" => "org.wildfly.security.policy",
"dynamic" => false
}],
"access-constraints" => {
"sensitive" => {"elytron-security" => {"type" => "elytron"}},
"application" => {"elytron-security" => {"type" => "elytron"}}
},
"attributes" => {
"custom-policy" => {
"type" => OBJECT,
"description" => "A custom policy provider definition.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["jacc-policy"],
"value-type" => {
"class-name" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"default-policy" => {
"type" => STRING,
"description" => "Not used.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "1.2.0",
"reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"jacc-policy" => {
"type" => OBJECT,
"description" => "A policy provider definition that sets up JACC and related services.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["custom-policy"],
"value-type" => {
"policy" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
"min-length" => 1L,
"max-length" => 2147483647L
},
"configuration-factory" => {
"type" => STRING,
"description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}]
}
{code}
Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
Secondly this provides two primary functions.
1. Instantation of [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html] and registration via a call to [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...]
This first point needs a class name for the policy as well as a module.
2. Registration of the JVM wide [https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/...] again needing a classname and module.
This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
It may make sense for JACC to move to it's own subsystem for a couple of reasons.
The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
It probably should also be possible to independently set the module for Policy and PolicyContextHandler as these will presently be shared.
was:
At the moment this resource is quite verbose but the tasks it performs are very simple.
{code}
[standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
{
"outcome" => "success",
"result" => [{
"address" => [
("subsystem" => "elytron"),
("policy" => "*")
],
"outcome" => "success",
"result" => {
"description" => "A definition that sets up a policy provider.",
"max-occurs" => 1,
"capabilities" => [{
"name" => "org.wildfly.security.policy",
"dynamic" => false
}],
"access-constraints" => {
"sensitive" => {"elytron-security" => {"type" => "elytron"}},
"application" => {"elytron-security" => {"type" => "elytron"}}
},
"attributes" => {
"custom-policy" => {
"type" => OBJECT,
"description" => "A custom policy provider definition.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["jacc-policy"],
"value-type" => {
"class-name" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"default-policy" => {
"type" => STRING,
"description" => "Not used.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"deprecated" => {
"since" => "1.2.0",
"reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"jacc-policy" => {
"type" => OBJECT,
"description" => "A policy provider definition that sets up JACC and related services.",
"expressions-allowed" => false,
"required" => true,
"nillable" => true,
"alternatives" => ["custom-policy"],
"value-type" => {
"policy" => {
"type" => STRING,
"description" => "The name of a java.security.Policy implementation referencing a policy provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
"min-length" => 1L,
"max-length" => 2147483647L
},
"configuration-factory" => {
"type" => STRING,
"description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
"min-length" => 1L,
"max-length" => 2147483647L
},
"module" => {
"type" => STRING,
"description" => "The name of the module to load the provider from.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
}
},
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {}
}
}]
}
{code}
Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
Secondly this provides two primary functions.
1. Instantation of https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html and registration via a call to https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...
This first point needs a class name for the policy as well as a module.
2. Registration of the JVM wide https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/... again needing a classname and module.
This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
It may make sense for JACC to move to it's own subsystem for a couple of reasons.
The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
> The /subsystem=elytron/policy=* can be simplified a lot further
> ---------------------------------------------------------------
>
> Key: WFCORE-5022
> URL: https://issues.redhat.com/browse/WFCORE-5022
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 12.0.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta2
>
>
> At the moment this resource is quite verbose but the tasks it performs are very simple.
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "elytron"),
> ("policy" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "A definition that sets up a policy provider.",
> "max-occurs" => 1,
> "capabilities" => [{
> "name" => "org.wildfly.security.policy",
> "dynamic" => false
> }],
> "access-constraints" => {
> "sensitive" => {"elytron-security" => {"type" => "elytron"}},
> "application" => {"elytron-security" => {"type" => "elytron"}}
> },
> "attributes" => {
> "custom-policy" => {
> "type" => OBJECT,
> "description" => "A custom policy provider definition.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["jacc-policy"],
> "value-type" => {
> "class-name" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "default-policy" => {
> "type" => STRING,
> "description" => "Not used.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "1.2.0",
> "reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "jacc-policy" => {
> "type" => OBJECT,
> "description" => "A policy provider definition that sets up JACC and related services.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["custom-policy"],
> "value-type" => {
> "policy" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "configuration-factory" => {
> "type" => STRING,
> "description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }]
> }
> {code}
> Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
> Secondly this provides two primary functions.
> 1. Instantation of [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html] and registration via a call to [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...]
> This first point needs a class name for the policy as well as a module.
> 2. Registration of the JVM wide [https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/...] again needing a classname and module.
> This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
> The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
> We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
> It may make sense for JACC to move to it's own subsystem for a couple of reasons.
> The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
> The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
> Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
> It probably should also be possible to independently set the module for Policy and PolicyContextHandler as these will presently be shared.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5020) Although elytron has module for JACC factory it is not used for JACC
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5020?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5020:
-------------------------------------
Description:
A module can be specified and this is used to load the specified provider class and instantiate it, however this is separate to the one instantiated by PolicyConfigurationFactory.
Elytron does set a system property to ensure the configured class name is used but does not actually ensure the module is used for class loading.
At the same time it should be ensuring there is only a single instance of the class.
Finally we should verify the correct class has been loaded in case some race condition has caused premature initialisation - those can be difficult to debug.
was:
A module can be specified and this is used to load the specified provider class and instantiate it, however this is separate to the one instantiated by PolicyConfigurationFactory.
Elytron does set a system property to ensure the configured class name is used but does not actually ensure the module is used for class loading.
At the same time it should be ensuring there is only a single instance of the class.
> Although elytron has module for JACC factory it is not used for JACC
> --------------------------------------------------------------------
>
> Key: WFCORE-5020
> URL: https://issues.redhat.com/browse/WFCORE-5020
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta2
>
>
> A module can be specified and this is used to load the specified provider class and instantiate it, however this is separate to the one instantiated by PolicyConfigurationFactory.
> Elytron does set a system property to ensure the configured class name is used but does not actually ensure the module is used for class loading.
> At the same time it should be ensuring there is only a single instance of the class.
> Finally we should verify the correct class has been loaded in case some race condition has caused premature initialisation - those can be difficult to debug.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months