[JBoss JIRA] (ELY-473) True credential forwarding support
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-473?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-473:
---------------------------------
Fix Version/s: 1.1.0.Beta7
(was: 1.1.0.Beta6)
> True credential forwarding support
> ----------------------------------
>
> Key: ELY-473
> URL: https://issues.jboss.org/browse/ELY-473
> Project: WildFly Elytron
> Issue Type: Enhancement
> Reporter: David Lloyd
> Priority: Minor
> Fix For: 1.1.0.Beta7
>
>
> Now we are ready for true support for forwarding credentials.
> The credentials should be associated with the SecurityIdentity itself. A permission check is required to acquire them (maybe even both a code permission check *and* a user authorization check).
> We could support holding one credential per type+algorithm combination, or simply a list of credentials which can be queried.
> Authentication client API should be enhanced to search a security domain's current identity for a forwarding credential to use.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-153) Support DigestCredential with a specified realm name
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-153?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-153:
---------------------------------
Fix Version/s: 1.1.0.Beta7
(was: 1.1.0.Beta6)
> Support DigestCredential with a specified realm name
> ----------------------------------------------------
>
> Key: ELY-153
> URL: https://issues.jboss.org/browse/ELY-153
> Project: WildFly Elytron
> Issue Type: Sub-task
> Components: Passwords
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta7
>
>
> This would imply the password is retrievable and the realm associated by the authentication mechanism.
> I see the following scenarios to be covered by this: -
> - Realm that does not store pre-hashed and so is open to the mechanism providing the realm name.
> - Realms where one or more realm names may be in use.
> - One identity with multiple credentials each with a different realm.
> - Different realms used for different identities but no more than one per identity.
> If this is accomplished using a CallbackHandler then there are couple of Callback options: -
> 1. getCredentialSupport on the realm, a RealmChoiceCallback can be used by a realm that advertises all the realm names it knows, where realm names are selected the response can take into account if all or some of the identities in that realm have a credential stored for that realm.
> 2. getCredentialSupport on the realm can also support RealmCallback, in this case the mechanism specifies one realm name.
> 3. These two can be repeated on the RealmIdentity, in that case however as a specific identity is being referenced the response can be much more specific.
> 4. On getCredential the Callbacks can both be supported but in both cases can allow the selection of a single realm.
> Another option could be an extension to RealmChoiceCallback that also indicates the level of support for each realm it contains.
> Whilst exploring this, being able to identify the message digest algorithm support level should also be considered in parallel.
> Also I see solving this as a simple pre-requisite for ELY-154
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-376) Password policies
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-376?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-376:
---------------------------------
Fix Version/s: 1.1.0.Beta7
(was: 1.1.0.Beta6)
> Password policies
> -----------------
>
> Key: ELY-376
> URL: https://issues.jboss.org/browse/ELY-376
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI, Passwords, Realms
> Reporter: Darran Lofthouse
> Assignee: David Lloyd
> Fix For: 1.1.0.Beta7
>
>
> Probably needs a design discussion first but we need to review where password policies fit in to the overall solution.
> We may say that policy handling is really the responsibility of the actual realm implementation, after all items such as history are going to be very realm specific.
> However there may also be a case in the generic sense that where a modifiable realm is in use a policy is desired to cover the complexity of any passwords set on that realm.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-298:
---------------------------------
Fix Version/s: 1.1.0.Beta7
(was: 1.1.0.Beta6)
> load-from/uri keystore xsd/parser mismatch
> ------------------------------------------
>
> Key: ELY-298
> URL: https://issues.jboss.org/browse/ELY-298
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Client
> Reporter: Kabir Khan
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta7
>
>
> The xsd has
> {code}
> <xsd:complexType name="key-store-type">
> <xsd:sequence minOccurs="1" maxOccurs="1">
> <!-- Access source type -->
> <xsd:choice minOccurs="1" maxOccurs="1">
> <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/>
> {code}
> The parser seems to look for 'uri' rather than 'load-from'
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1059) Drools can't find rules under stress
by Massinissa BOUZIAD (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1059?page=com.atlassian.jira.plugi... ]
Massinissa BOUZIAD commented on DROOLS-1059:
--------------------------------------------
Hi [~mfusco],
I tried with version 6.4.0-SNAPSHOT (last snapshot example : drools-compiler-6.4.0-20160405.090748-648.jar) and my unit tests do not pass getting a new stack :
{panel:title= Regression}
java.lang.ArrayIndexOutOfBoundsException: 3
at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:304) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:311) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.PhreakQueryTerminalNode.checkAndTriggerQueryReevaluation(PhreakQueryTerminalNode.java:173) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:78) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278) ~[drools-core-6.4.0-SNAPSHOT.jar:6.4.0-SNAPSHOT]
at com.darty.pricing.core.delivery.DeliveryFeesEvaluator.evaluate(DeliveryFeesEvaluator.java:87) ~[classes/:na]
{panel}
> Drools can't find rules under stress
> ------------------------------------
>
> Key: DROOLS-1059
> URL: https://issues.jboss.org/browse/DROOLS-1059
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 6.4.0.Final, 7.0.0.Final
>
> Attachments: DroolsBugReproducerTest.java, reproducerRule.drl
>
>
> In my knowledge base, I have many rules.
> All of them are working very well in production with drools 6.0.1-FINAL even in stress condition hight trafic (arount 40 hits seconds)
> This bug append when we made an upgrade with drools 6.3.0-FINAL which is compatible with jdk8 mandatory in my case.
> So now when I put my rules under stress test (benchmarking) I got this random error.
> Drools is unable to find a query (not always the same one).
> I got this error for 0,6% of my requests.
> *+Following the stack trace : +*
> Unable to find query 'checkAndBindBasket'
> at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:167) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6494) Improve Undertow subsystem plugability
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6494:
------------------------------------
Summary: Improve Undertow subsystem plugability
Key: WFLY-6494
URL: https://issues.jboss.org/browse/WFLY-6494
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Stuart Douglas
Assignee: Stuart Douglas
It should be easy for other subsystems/MSC based code to plug into the Undertow subsystem
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6485) add JPA dependency in subdeployments to avoid NPE
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6485?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6485:
------------------------------------
Hi [~smarlow], I've just noticed this line: [WeldDeploymentProcessor.java#L183|https://github.com/wildfly/wildfly/blob...]. And I wonder whether changing the line to {{getJpaDependencies(subDeployment, jpaServices)}} couldn't fix the issue?
> add JPA dependency in subdeployments to avoid NPE
> --------------------------------------------------
>
> Key: WFLY-6485
> URL: https://issues.jboss.org/browse/WFLY-6485
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
>
> WeldDeploymentProcessor only processes top level deployments (subdeployments are skipped). This means that subdeployments that CDI inject a persistence unit/context, will not add a dependency on the JPA PersistenceUnitService. As a result, the PersistenceUnitService is referenced before it is started (which leads to PersistenceUnitService.entityManagerFactory being null).
> We should avoid the following NPE by ensuring that dependencies on the JPA persistence unit are added for all sub-deployments.
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.createEntityManager(TransactionScopedEntityManager.java:186)
> at org.jboss.as.jpa.container.TransactionScopedEntityManager.getEntityManager(TransactionScopedEntityManager.java:91)
> at org.jboss.as.jpa.container.AbstractEntityManager.find(AbstractEntityManager.java:212)
> {quote}
> Potential fix is at [https://github.com/scottmarlow/wildfly/tree/jpaNPE]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Andrei Serea (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Andrei Serea commented on WFLY-3858:
------------------------------------
And Wildfly 10...
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month