In our case it was the OTP SASL mechanism.
If the equivalent behaviour was to be implemented for HTTP I would
assume something similar would be required.
Regards,
Darran Lofthouse.
On 21/10/15 12:21, arjan tijms wrote:
> Hi,
>
> On Wed, Oct 21, 2015 at 12:20 PM, Darran Lofthouse
> <darran.lofthouse_at_redhat.com <mailto: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
>
>
>