[JBoss JIRA] (ELY-54) Support for stronger hashes as alternatives to MD5
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-54:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
> Key: ELY-54
> URL: https://issues.jboss.org/browse/ELY-54
> Project: WildFly Elytron
> Issue Type: Feature Request
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (ELY-36) Server Authentication Context Lifecycle
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-36?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-36:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Server Authentication Context Lifecycle
> ---------------------------------------
>
> Key: ELY-36
> URL: https://issues.jboss.org/browse/ELY-36
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The authentication context is used with a sequence of calls during the authentication process, this task is to look into how we can apply a lifecycle to that so that appropriate clean up can be performed.
> This could be closely related to ELY-35 which specifically looks at outcome notification.
> When considering a lifecycle I think we have two key events to think about, the most natural one being once the authentication process is complete regardless of outcome - however should also consider intermediate responses going back to the client - we do not want to be holding onto expensive resources once we pass control back to the client as that risks a Dos based attack.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (ELY-53) GSSAPI Make Delegated Credential Available
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-53?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-53:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> GSSAPI Make Delegated Credential Available
> ------------------------------------------
>
> Key: ELY-53
> URL: https://issues.jboss.org/browse/ELY-53
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> The server side of the mechanism can receive a delegated credential but there is no way to obtain it, we should provide a way for it to be obtained or provided.
> _Note: This may be an Elytron integration point rather than something supported in the pure SASL mechanism._
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (ELY-11) Interoperability Testing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-11?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-11:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Interoperability Testing
> ------------------------
>
> Key: ELY-11
> URL: https://issues.jboss.org/browse/ELY-11
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> This does not necessarily belong here as it may be an independent project of it's own but for now here it is.
> WildFly-Elytron and WildFly-SASL are going to be used with different providers of the SPI exposed by these projects, rather than waiting until we are integrating within WildFly we should create project(s) to test the interoperability of these two projects with potential projects that will implement the SPI.
> The interoperability testing will predominantly validate two areas: -
> 1 - The SPIs being exposed by these project for the integration of different providers is actually valid.
> 2 - The implementation and APIs of the related providers are in fact capable of meeting the requirements for WildFly.
> The sooner we can identify any mis-match in this area the better to give us time to work out the solution.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months