[JBoss JIRA] (ELY-573) Programatic authentication
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-573?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-573:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> Programatic authentication
> --------------------------
>
> Key: ELY-573
> URL: https://issues.jboss.org/browse/ELY-573
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta8
>
>
> This is critical as it risks changing defined APIs and SPIs but we need to cover programatic authentication.
> It is however possible this is handled within the app server integration and not within our framework but we have two predominant cases: -
> - Servlet calls authenticate which means our mechanisms need to be triggered to challenge the client.
> - Servlet calls login with a username and password.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-565) A first boot SSLContext
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-565?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-565:
---------------------------------
Fix Version/s: 1.1.0.Beta8
(was: 1.1.0.Beta7)
> A first boot SSLContext
> -----------------------
>
> Key: ELY-565
> URL: https://issues.jboss.org/browse/ELY-565
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Fix For: 1.1.0.Beta8
>
>
> For developers we have a requirement to be able to provide a working SSL set up before the user configures their own keys and certificates. We will need to tie this with our other SSL related tasks for fully configures set ups but we probably are also going to require an automatic mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[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)
8 years, 5 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)
8 years, 5 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)
8 years, 5 months