Hi,
On Wed, Oct 21, 2015 at 12:20 PM, Darran Lofthouse <
darran.lofthouse_at_redhat.com> wrote:
> The work we are undertaking within WildFly we have some cases where
> mechanisms require a modifiable store but these are fairly limited.
Interesting, what is exactly going to be modified?
In my understanding the modifiable identity store is not off the table, but
to be defined as an optional capability later. I think we have 3 levels of
functionality:
1. Basic read-only. This has very few requirements, just:
1. A minimal interface with only the "CredentialValidationResult
validate(Credential credential)" method
2. A specified way of how app developers and ops alike specify which
store is to be used
3. A specified way of how mechanisms obtain a reference to the store
4. A few sub-classes/interfaces for the Credential type
2. Extended read-only. Useful for somewhat advanced scenarios. This
includes the above plus:
1. API to query the store beyond simply providing a single credential
2. A convenience abstract base class that stores can optionally inherit
from
3. Facility for plugable Credential support that store implementations
can optionally use
3. Full read/write. Contains all of the above plus:
1. Ability to save and update identity data
Basic read-only should be enough for what each existing authentication
mechanism needs today. For the open source servers it can actually be seen
that it should be enough if I analysed them correctly (see
http://arjan-tijms.omnifaces.org/2015/10/how-servlet-containers-all-implement.html
).
Kind regards,
Arjan Tijms