[JBoss JIRA] (ELY-524) Caching support in the LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-524:
---------------------------------
Fix Version/s: 1.1.0.Beta11
(was: 1.1.0.Beta10)
> Caching support in the LDAP realm
> ---------------------------------
>
> Key: ELY-524
> URL: https://issues.jboss.org/browse/ELY-524
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta11
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-509) Multi Step HTTP Authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-509?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-509:
---------------------------------
Fix Version/s: 1.1.0.Beta11
(was: 1.1.0.Beta10)
> Multi Step HTTP Authentication
> ------------------------------
>
> Key: ELY-509
> URL: https://issues.jboss.org/browse/ELY-509
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta11
>
>
> This is a variation of FORM authentication and closely related to ELY-508.
> The scenario would be prompt for a username, then prompt for a password and if the password is valid and the account supports OTP prompt for the OTP.
> The mechanism may also be responsible for sending the OTP but that is probably a side topic.
> I have raised this in terms of being a HTTP mechanism but the main point we need to ensure is covered is the requirements about identifying what checks are required for a specific user and tracking they are all complete.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-477:
---------------------------------
Fix Version/s: 1.1.0.Beta11
(was: 1.1.0.Beta10)
> XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK
> ----------------------------------------------------------
>
> Key: ELY-477
> URL: https://issues.jboss.org/browse/ELY-477
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.1.0.Beta4
> Reporter: Ondrej Lukas
> Fix For: 1.1.0.Beta11
>
>
> Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with:
> {code}
> expected:<-1> but was:<7>
> and stacktrace:
> java.lang.AssertionError: expected:<-1> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96)
> ...
> {code}
> It is caused by undefined line number of XML parsing failure for IBM JDK.
> Stacktrace of checked XMLStreamException for IBM JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException:
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> at authentication-client.xml:
> at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
> ...
> {code}
> Stacktrace of checked XMLStreamException for Oracle JDK:
> {code}
> org.wildfly.client.config.ConfigXMLParseException:
> CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered
> at authentication-client.xml:7:39:
> at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181)
> at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118)
> at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months