[JBoss JIRA] (ELY-183) Protocols for password changing
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-183:
---------------------------------
Fix Version/s: (was: 1.3.0.CR1)
> Protocols for password changing
> -------------------------------
>
> Key: ELY-183
> URL: https://issues.jboss.org/browse/ELY-183
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: Darran Lofthouse
>
> Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-)
> A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options.
> Are there any existing protocols to remotely set a password securely?
> Is there anything specific to our current password types we can take advantage of?
> Are there features of any of our SASL mechanisms to apply a second layer of confidentiality?
> Any other options?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-929:
---------------------------------
Fix Version/s: (was: 1.3.0.CR1)
> AuthenticationConfiguration uniqueness enhancements
> ---------------------------------------------------
>
> Key: ELY-929
> URL: https://issues.jboss.org/browse/ELY-929
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: David Lloyd
>
> Apply some enhancements to AuthenticationConfiguration uniqueness.
> * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler
> The following also may be possible and useful:
> * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}}
> * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months