Step 1 of 4: Choose Issues


Key Summary Description

ELY-14 Add a file-backed realm implementation

Add a filesystem-backed realm implementation.


ELY-14 Implement a KeyStore backed by a more complete file representation.

This task is also probably part research to verify it is actually needed, however the ability for a more complete file based store which supports the stronger password types and also potentially can be exposed by WildFly for management purposes could be desirable.


ELY-14 Create a JAAS based security realm.

Legacy integration is always going to be a concern so should verify that we can delegate to JAAS if required.

Delegating to JAAS is always going to simplify the password types supported so this is more of an ensure we can integrate with JAAS rather than ensure we can fully integrate with JAAS.


ELY-14 Add support to verify a password to LDAP realm

This is to add support to take a clear text password and use it to connect to LDAP to verify the users identity.

Note: This is provided for legacy purposes rather than as a preferred solution. Ideally either one of the solutions which retrieves the password from LDAP would be used or GSSAPI depending on the overall architecture.


ELY-14 authPassword LDAP attribute - add support for RFC5803

RFC5803 adds support for storing SCRAM secrets in the 'authPassword' attribute introduced by RFC3112


ELY-14 Expand LDAP realm to support authPassword attribute (RFC3112)

RFC3112 adds a new attribute 'authPassword' and can be used to store passwords in various formats.


ELY-14 Where does OTP fit into realms?

Will investigate further once we have a pure LDAP impl in.

We could have an architecture where we have an LDAP server that is then referenced by an OTP server or we could have the two somehow combined into one.

There are also requirements related to marking a token as used or token invalidation after too many bad attempts - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.


ELY-14 OAuth Broker Security Realm


ELY-14 Add PicketLink based realm implementation


ELY-14 Add KeyStore based realm implementation


ELY-14 Add a RFC2256 based LDAP Realm

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: -

( NAME 'userPassword' DESC 'RFC2256/2307: password of user' EQUALITY octetStringMatch SYNTAX USAGE userApplications X-SCHEMA 'system' )

ELY-14 Add a KeyStore implementation compatible with the existing WildFly properties file used for security realms.

This is the file format currently used with passwords pre-digested for use with Digest MD5 (HTTP and SASL) authentication.