[JBoss JIRA] (ELY-969) Add a KeyStore implementation that can use the key store password for retrieving entries.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-969?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-969:
------------------------------------
Assignee: (was: Darran Lofthouse)
> Add a KeyStore implementation that can use the key store password for retrieving entries.
> -----------------------------------------------------------------------------------------
>
> Key: ELY-969
> URL: https://issues.jboss.org/browse/ELY-969
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: KeyStores
> Reporter: Darran Lofthouse
> Fix For: 1.2.0.Beta1
>
>
> A KeyManager which uses a KeyStore is defined independently of the KeyStore - it is the KeyManager that has the password for the entry in the KeyStore whilst the KeyStore has the password for the overall store.
> In many cases the password used for the overall store is the same password as used for the entries.
> We should provide a KeyStore implementation that can substitute the password received.
> We may even be able to go one step further and add a password resolver which could mean a CredentialStore is used to obtain the password for different entries,
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-16) Add a RFC2256 based LDAP Realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-16?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse reassigned ELY-16:
-----------------------------------
Assignee: (was: Darran Lofthouse)
> Add a RFC2256 based LDAP Realm
> ------------------------------
>
> Key: ELY-16
> URL: https://issues.jboss.org/browse/ELY-16
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Fix For: 2.0.0.Alpha1
>
>
> RFC2256 defines the userPassword attribute on LDAP entries, officially this is supposed to be clear text - however many vendors now support a one way hash where the hash algorithm is specified at the beginning of the attribute value: -
> {noformat}
> {ssha}izu672WN0xA2ZaYofeiWyQ5QKxEBMNsbyQKwRw==
> {noformat}
> {noformat}
> ( 2.5.4.35 NAME 'userPassword' DESC 'RFC2256/2307: password of user' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 USAGE userApplications X-SCHEMA 'system' )
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1192?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1192:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> HTTP status 500 when no principal is returned by aggregate-principal-transformer
> --------------------------------------------------------------------------------
>
> Key: ELY-1192
> URL: https://issues.jboss.org/browse/ELY-1192
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta42
> Reporter: Ondrej Lukas
>
> In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process.
> This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers).
> This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain.
> [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months