[JBoss JIRA] (ELY-1186) Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1186?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1186:
-------------------------------------
Assignee: David Lloyd (was: Darran Lofthouse)
> Elytron - authentication fails when a realm name is not specified for DIGEST-MD5 mechanism on server side
> ---------------------------------------------------------------------------------------------------------
>
> Key: ELY-1186
> URL: https://issues.jboss.org/browse/ELY-1186
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 1.1.0.Beta54
>
>
> When a default configuration is used for DIGEST-MD5 SASL mechanism, then server suggest hostname as a realm name, but authentication fails because ServerAuthenticationContext checks mechanism configuration and fails with following exception:
> {code}
> @Message(id = 1092, value = "Invalid mechanism realm selection \"%s\"")
> IllegalArgumentException invalidMechRealmSelection(String realmName);
> {code}
> *Suggested fix:*
> If the server suggests realm name, then it should be able to consume it. Or if the realm name is really mandatory, then server should not suggest such a default value. IMO allowing such a default and simplifying configuration would have positive impact on user experience.
> The full stacktrace (hidden):
> {noformat}
> javax.security.sasl.SaslException: ELY05053: [DIGEST-MD5] Callback handler failed for unknown reason [Caused by java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"]
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:105)
> at org.wildfly.security.sasl.digest.AbstractDigestMechanism.getPredigestedSaltedPassword(AbstractDigestMechanism.java:482)
> at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:259)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:355)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:328)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:470)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:897)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: ELY01092: Invalid mechanism realm selection "localhost"
> at org.wildfly.security.auth.server.ServerAuthenticationContext$InitialState.setMechanismRealmName(ServerAuthenticationContext.java:1615)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setMechanismRealmName(ServerAuthenticationContext.java:712)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:927)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:735)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:101)
> ... 15 more
> {noformat}
> Attached also server configuration and WireShark log.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled
by KimJohn Quinn (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ]
KimJohn Quinn commented on DROOLS-1624:
---------------------------------------
Here is a test case one of our guys put together that demonstrates the difference between watch and no-watch rules. We tried to cobble it together to be more representative of what we are doing and it is very similar.
In our example, the data facts are based off of Guava's ForwardingMap. We extend it to create strong-typed facts that have explicit properties (get/set) but the bulk of our constraining is performed against the map properties. Throughout our rule session we generally are adding to the map from one rule and checking for those properties in another rule.
Let me know if this provides any additional insight or if there is something different we should be doing internally.
[^drools.zip]
> Map Handling with Property Reactive Always Enabled
> --------------------------------------------------
>
> Key: DROOLS-1624
> URL: https://issues.jboss.org/browse/DROOLS-1624
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Environment: * JDK8
> * Docker running Alpine
> Reporter: KimJohn Quinn
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: drools.zip
>
>
> Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco...
> We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules.
> In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that.
> Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session.
> Watch for changes to the Map properties
> If a certain property or properties exist a 'populate' rule fires (calls modify())
> The populate rule enriches the map fact. (calls modify())
> Based on #3, more rules fire when certain properties exist (calls modify())
> We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.
> I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
> In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?
> In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?
> For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single....
> I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco)....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1624) Map Handling with Property Reactive Always Enabled
by KimJohn Quinn (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1624?page=com.atlassian.jira.plugi... ]
KimJohn Quinn updated DROOLS-1624:
----------------------------------
Attachment: drools.zip
> Map Handling with Property Reactive Always Enabled
> --------------------------------------------------
>
> Key: DROOLS-1624
> URL: https://issues.jboss.org/browse/DROOLS-1624
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.0.0.Final
> Environment: * JDK8
> * Docker running Alpine
> Reporter: KimJohn Quinn
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: drools.zip
>
>
> Referencing a conversation on [Google Groups - Drools Usage|https://groups.google.com/forum/?fromgroups#!topic/drools-usage/G7r...] and as requested by Mario Fusco...
> We currently have a ruleset that relies heavily on Map facts. In Drools 6.5 we fire approximately 400 rules.
> In Drools 7.0 we get only about 50 rules unless we add the "<property key="drools.propertySpecific" value="ALLOWED"/>" to the kmodule.xml, in which case we fire the full 400 rules or by using @Watch(*) or @Watch(!*) on the rules. It "seems" like only the first evaluations of the rules are firing and then no others after that.
> Our flow generally follows something like below, within a stateful session, using rules only. We fire all rules per-request then close the session.
> Watch for changes to the Map properties
> If a certain property or properties exist a 'populate' rule fires (calls modify())
> The populate rule enriches the map fact. (calls modify())
> Based on #3, more rules fire when certain properties exist (calls modify())
> We are work heavily with rules that depend on loaded available facts up-front and computed properties throughout evaluation.
> I have a couple of usage questions regarding Drools 7, the default enabling of Property Reactive and using Maps as the facts:
> In general, how do maps work with property reactive and respond to modify/insert events? Does Drools look at the Map as a whole, any change re-evaluates the tree, or each individual property within the map re-evaluates the change?
> In Drools 7, by defaulting the property reactive setting, does that mean all rules need to be annotated or they should they work as is (dao or map-based facts) when using modify/insert?
> For reference, we are relying on this doco https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single....
> I am looking into details or an example how to properly use Maps in Drools 7 with Property Reactive features always enabled (as suggested per the doco)....
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1629) PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
by Manuel Castro (JIRA)
Manuel Castro created DROOLS-1629:
-------------------------------------
Summary: PersisteHelper and ObjectMarshallingStrategyStore are mixing ObjectMarshallingStrategies
Key: DROOLS-1629
URL: https://issues.jboss.org/browse/DROOLS-1629
Project: Drools
Issue Type: Bug
Components: core engine, kie server
Affects Versions: 6.5.0.Final, 6.4.0.Final
Reporter: Manuel Castro
Assignee: Mario Fusco
We are defining our custom JPAPlaceHolderResolverStrategy, parametrizing the constructuctor with the persistence unit name it handles.
When we need two of them to handle different kind of Entities probably from different DataSources, the marshalling process works properly as calling to accept method before marshalling returns true for the correct ObjectMarshallingStrategy.
The problem occurs while unmarshalling the entities. As the class name is being used to find the correct ObjectMarshallingStrategy from the store, the class name matches two Object Marshalling Strategies, so the first one found is returned, making the environment work in a random space.
This problem could be solved adding to ObjectMarshallingStrategy interface a getName() method in order to be able to avoid the usage of the getClass().getName() approach is being used now.
Then PersisteHelper must use this method to store the ProtobufferHeader and then ObjectMarshallingStrategyStore must use the method to retrieve the appropiate implementation.
In order to enable backward compatibility a NamedObjectMarshallingStrategyInterface could be added to be invoked only for updated implementors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years