[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)
9 years
[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)
9 years