[JBoss JIRA] (ELY-558) Introduce generalized support for authentication timeout of mechanisms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-558?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-558:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> Introduce generalized support for authentication timeout of mechanisms
> ----------------------------------------------------------------------
>
> Key: ELY-558
> URL: https://issues.jboss.org/browse/ELY-558
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Mechanisms, Utils
> Reporter: David Lloyd
> Assignee: Farah Juma
> Fix For: 1.1.0.Beta8
>
>
> Paraphrasing from HipChat discussion.
> Generic mechanism wrappers for handling authentication timeout will not only support OTP-style credential read-modify-write authentication mechanisms, but generally avoid certain DoS conditions and failure states that would be associated with long locking of credentials (even in the read case).
> This issue is to implement a wrapping mechanism factory (for at least SASL and possibly HTTP as well, eventually) which supports authentication timeout by judicious usage of concurrency primitives and timed executors. It is important to guarantee thread-safe access to the underlying mechanism, which are generally concurrency-unsafe.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[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.Beta8
(was: 1.1.0.Beta7)
> 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
> Priority: Critical
> Fix For: 1.1.0.Beta8
>
>
> 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, 9 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.Beta8
(was: 1.1.0.Beta7)
> 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.Beta8
>
>
> 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, 9 months