[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}
[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.
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.
> 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.Beta1
>
>
> 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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (JBJCA-1409) Publish JDBC local rar with all dependencies
by Thiago Henrique Hüpner (Jira)
Thiago Henrique Hüpner created JBJCA-1409:
---------------------------------------------
Summary: Publish JDBC local rar with all dependencies
Key: JBJCA-1409
URL: https://issues.redhat.com/browse/JBJCA-1409
Project: IronJacamar
Issue Type: Feature Request
Components: JDBC
Reporter: Thiago Henrique Hüpner
Currently, there is the JDBC local artifact here. [https://mvnrepository.com/artifact/org.jboss.ironjacamar/jdbc-local/1.4.2...]
However, it only includes ironjacamar-local.jar. It is not usable outside a container providing both jboss-logging and ironjacamar-core-api.
I want to use the Iron Jacamar JDBC resource adapter in the Open Liberty application server, but I would have to include both jars manually. If there is a way to pack all dependencies inside the _RAR_ file, it would be more reusable, or at least, easier.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ]
Kris Verlaenen reassigned DROOLS-5454:
--------------------------------------
Assignee: Edson Tirelli (was: Kris Verlaenen)
> Please bring back the IDE-based 'Guided Rule Editor'
> ----------------------------------------------------
>
> Key: DROOLS-5454
> URL: https://issues.redhat.com/browse/DROOLS-5454
> Project: Drools
> Issue Type: Feature Request
> Components: eclipse plugin
> Affects Versions: 7.39.0.Final
> Reporter: Rick Wagner
> Assignee: Edson Tirelli
> Priority: Major
>
> JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version.
>
> Please bring back the Guided Rule Editor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Rick Wagner (Jira)
[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ]
Rick Wagner commented on DROOLS-5454:
-------------------------------------
Hi [~KrisVerlaenen]
Certainly. In the BxMS 5 (and maybe 6) days, we offered a set of plug-ins for Eclipse / DevStudio. One of these was called the 'Guided Rules Editor', it is seen in section 8.6 of this doc [1].
Our user cannot find it in any fashion today (outside the web tools), they are requesting the return of this Eclipse-based tool.
Thanks,
Rick
[1] https://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html...
> Please bring back the IDE-based 'Guided Rule Editor'
> ----------------------------------------------------
>
> Key: DROOLS-5454
> URL: https://issues.redhat.com/browse/DROOLS-5454
> Project: Drools
> Issue Type: Feature Request
> Components: eclipse plugin
> Affects Versions: 7.39.0.Final
> Reporter: Rick Wagner
> Assignee: Kris Verlaenen
> Priority: Major
>
> JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version.
>
> Please bring back the Guided Rule Editor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (WFLY-13619) Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
by Andrej Kolontai (Jira)
[ https://issues.redhat.com/browse/WFLY-13619?page=com.atlassian.jira.plugi... ]
Andrej Kolontai updated WFLY-13619:
-----------------------------------
Steps to Reproduce:
The problem is reproducible with just one server by making the session store persistent.
My production setup is rather complex so I've created a tiny project just to show the effect: [https://github.com/andrejkolontai/jaspic-elytron-distributed-demo]
First, get a fresh wildfly distribution (version 20.0.0.Final) and unpack it.
Start it with standalone.sh.
Then, using jboss-cli.sh make the session store persistent:
{noformat}
/subsystem=infinispan/cache-container=web/local-cache=passivation/store=file:add(passivation=false,purge=false)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}[standalone@localhost:9990 /] reload
{noformat}
Then create an elytron security domain and connect it to undertow:
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/security-domain=elytronjaspic:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=elytronjaspic:add(integrated-jaspi=false,security-domain=elytronjaspic)
{"outcome" => "success"}
{noformat}
The demo project has a servlet, a session scoped cdi bean (counts the requests in a session) an a rather trivial authenticator which uses AutoApplySession.
To build it, use the gradle wrapper:
{noformat}
./gradlew war{noformat}
The repository has three tags to see the difference between old security subsystem and elytron.
First, the old security subsystem to ses how it's used to work:
{noformat}
git checkout old-security
Previous HEAD position was 6dad6c3 Changed security domain to the elytron one
HEAD is now at 547cff7 First Commmit
./gradlew war
BUILD SUCCESSFUL in 1s
2 actionable tasks: 1 executed, 1 up-to-date
cp build/libs/jaspic.war ~/devel/wildfly-20.0.0.Final/standalone/deployments/{noformat}
Verify that the authentication mechanism kicks in:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>{noformat}
call with authentication credentials:
{noformat}
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
verify that the authentication state is stored in the session (call without secret):
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 1{noformat}
reload/restart wildfly
verify the session has survived the reload:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 2{noformat}
Now, switch to elytron by changing the security domain:
{noformat}
git checkout elytron-security{noformat}
build & deploy like above
Now do the same procedure but clear the cookies first:
{noformat}
rm cookies
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
At this point you should see wildfly throwing exceptions. My demo application seems to work. But my production application would stop working. And the sessions are not actually persisted. One more effect in production: when a server is restarted, it takes a very long time for it to come back again because the running server is struggling to serialize the session data which is not possible while the restarting server is waiting for the cached session data to arrive. After a timeout, the affected applications would just go into .failed.
A possible workaround is to make the application non-distributable:
{noformat}
git checkout non-distributable{noformat}
build & deploy again like above. Repeat the test. Everything just works but, of course, the sessions are not persisted and in production there would be no session failover.
I could stay with the old security subsystem (like "jaspitest"). But I really like elytron better and words like "dummy" in a production configuration are kind of scary.
That's not much of an issue. But I liked the feeling that I could just redeploy an application or restart a server during normal work hours instead of waiting until midnight or so.
What is also interesting: it only seems to affect jaspic/jsr375 enabled applications. We have one application using form authentication backed by an ldap realm which doesen't seem to have this problem.
was:
The problem is reproducible with just one server by making the session store persistent.
My production setup is rather complex so I've created a tiny project just to show the effect: [https://github.com/andrejkolontai/jaspic-elytron-distributed-demo]
First, get a fresh wildfly distribution (version 20.0.0.Final) and unpack it.
Start it with standalone.sh.
Then, using jboss-cli.sh make the session store persistent:
{noformat}
/subsystem=infinispan/cache-container=web/local-cache=passivation/store=file:add(passivation=false,purge=false)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}[standalone@localhost:9990 /] reload
{noformat}
Then create an elytron security domain and connect it to undertow:
{noformat}
[standalone@localhost:9990 /] /subsystem=elytron/security-domain=elytronjaspic:add
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=elytronjaspic:add(integrated-jaspi=false,security-domain=elytronjaspic)
{"outcome" => "success"}
{noformat}
The demo project has a servlet, a session scoped cdi bean (counts the requests in a session) an a rather trivial authenticator which uses AutoApplySession.
To build it, use the gradle wrapper:
{noformat}
./gradlew war{noformat}
The repository has three tags to see the difference between old security subsystem and elytron.
First, the old security subsystem to ses how it's used to work:
{noformat}
git checkout old-security
Previous HEAD position was 6dad6c3 Changed security domain to the elytron one
HEAD is now at 547cff7 First Commmit
./gradlew warBUILD SUCCESSFUL in 1s
2 actionable tasks: 1 executed, 1 up-to-date
cp build/libs/jaspic.war ~/devel/wildfly-20.0.0.Final/standalone/deployments/{noformat}
Verify that the authentication mechanism kicks in:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>{noformat}
call with authentication credentials:
{noformat}
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
verify that the authentication state is stored in the session (call without secret):
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 1{noformat}
reload/restart wildfly
verify the session has survived the reload:
{noformat}
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
Hallo Welt 2{noformat}
Now, switch to elytron by changing the security domain:
{noformat}
git checkout elytron-security{noformat}
build & deploy like above
Now do the same procedure but clear the cookies first:
{noformat}
rm cookies
curl -w '\n' -c cookies -b cookies localhost:8080/jaspic/hallo
<html><head><title>Error</title></head><body>Unauthorized</body></html>
curl -w '\n' -c cookies -b cookies -H "secret: shampoo" localhost:8080/jaspic/hallo
Hallo Welt 0{noformat}
At this point you should see wildfly throwing exceptions. My demo application seems to work. But my production application would stop working. And the sessions are not actually persisted. One more effect in production: when a server is restarted, it takes a very long time for it to come back again because the running server is struggling to serialize the session data which is not possible while the restarting server is waiting for the cached session data to arrive. After a timeout, the affected applications would just go into .failed.
A possible workaround is to make the application non-distributable:
{noformat}
git checkout non-distributable{noformat}
build & deploy again like above. Repeat the test. Everything just works but, of course, the sessions are not persisted and in production there would be no session failover.
I could stay with the old security subsystem (like "jaspitest"). But I really like elytron better and words like "dummy" in a production configuration are kind of scary.
That's not much of an issue. But I liked the feeling that I could just redeploy an application or restart a server during normal work hours instead of waiting until midnight or so.
What is also interesting: it only seems to affect jaspic/jsr375 enabled applications. We have one application using form authentication backed by an ldap realm which doesen't seem to have this problem.
> Elytron: org.wildfly.security.auth.server.SecurityIdentity not Serializable
> ---------------------------------------------------------------------------
>
> Key: WFLY-13619
> URL: https://issues.redhat.com/browse/WFLY-13619
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final
> Reporter: Andrej Kolontai
> Assignee: Darran Lofthouse
> Priority: Minor
>
> Since the old security subsystem has been deprecated for a while I decided to move my applications to elytron which worked just fine up to the point where I tried to migrate an application that is:
> * distributed
> * uses Jaspic in form of a JSR375 HttpAuthenticationMechanism which has@AutoApplySession
> In the logs I see stacktraces like this:
>
> {noformat}
> 09:37:22,045 WARN [org.infinispan.PERSISTENCE] (default task-1) ISPN000559: Cannot marshall 'class org.infinispan.marshall.protostream.impl.MarshallableUserObject': java.io.NotSerializableException: org.wildfly.security.auth.server.SecurityIdentity
> at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:272)}}
> at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1141)}}
> at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1099)}}
> at org.jboss.marshalling.river@2.0.9.Final//org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:266)}}
> at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:58)}}
> at org.jboss.marshalling@2.0.9.Final//org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:111)}}
> .....
> Caused by: an exception which occurred:
> in field org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer.securityIdentity
> in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a
> in object org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl$IdentityContainer@7bf2af9a
> in object java.util.concurrent.ConcurrentHashMap@d02a9ca2
> in object org.wildfly.clustering.marshalling.jboss.SimpleMarshalledValue@d02a9ca2
> {noformat}
>
>
> Looks to me like it's trying to serialize the session to replicate it to the other nodes in the cluster and fails because the user identity, which is part of the session because of AutoApplySession, is not serializable. I have checked the source and it is really not serializable.
>
> I had no problems with the old security subsystem (i.e. jaspitest).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5442) [Guided Decision Table] Key navigation failure in Descision table
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5442:
--------------------------------
Summary: [Guided Decision Table] Key navigation failure in Descision table (was: Key navigation failure in Descision table)
> [Guided Decision Table] Key navigation failure in Descision table
> -----------------------------------------------------------------
>
> Key: DROOLS-5442
> URL: https://issues.redhat.com/browse/DROOLS-5442
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Toni Rikkola
> Priority: Major
> Labels: decision_table
> Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png
>
>
> When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables.
> !image-2020-06-18-15-04-15-605.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5442) [Guided Decision Table] Key navigation failure in Descision table
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5442:
--------------------------------
Labels: decision_table drools-tools (was: decision_table)
> [Guided Decision Table] Key navigation failure in Descision table
> -----------------------------------------------------------------
>
> Key: DROOLS-5442
> URL: https://issues.redhat.com/browse/DROOLS-5442
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Toni Rikkola
> Priority: Major
> Labels: decision_table, drools-tools
> Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png
>
>
> When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables.
> !image-2020-06-18-15-04-15-605.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months
[JBoss JIRA] (DROOLS-5442) Key navigation failure in Descision table
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5442?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5442:
--------------------------------
Tester: Jozef Marko
> Key navigation failure in Descision table
> -----------------------------------------
>
> Key: DROOLS-5442
> URL: https://issues.redhat.com/browse/DROOLS-5442
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Toni Rikkola
> Priority: Major
> Labels: decision_table
> Attachments: arrow.webm, image-2020-06-18-15-04-15-605.png, image-2020-06-18-15-06-26-220.png
>
>
> When user navigates among columns from Description to any other - he need to push right arrow key twice to skip a hidden column introduced recently for decision tables.
> !image-2020-06-18-15-04-15-605.png|thumbnail!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 3 months