[wildfly-dev] Plugging in Credential Store backed ExpressionResolver

[Brian Stansberry]

Sorry for the late reply. :(

On Tue, Jul 9, 2019 at 12:54 PM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> Presently working on WFCORE-4360 adding support for expression resolution
> backed by a credential store - the main barrier is going to be the solution
> to bridge expression resolution with a subsystem provided component.
>
> Parallel boot being the big problem, as there is no ordering of operation
steps across subsystems.


> I am wondering if the following is going to be viable to support a
> configurable expression resolver from a subsystem.
>
> I see the RuntimeExpressionResolver is created very early in the boot
> process, however at the time it is created the CapabilityRegistry is also
> available. This is making me think if the CapabilityRegistry can be passed
> in to the RuntimeExpressionResolver.
>

Sounds reasonable.

>
> I would then imagine the resource handling expression resolution would
> register a non-dynamic capability which exposes an expression resolver
> runtime API.
>

It's a runtime API so the object is created in Stage.MODEL when the
capability is registered, so it is available at the start of Stage.RUNTIME.
So, so far ok...

This in turn may also need to cross reference a credential store which
> would also need to be accessible using the runtime API of a capability.
>

again a runtime API so the object is created in Stage.MODEL so available at
the start of Stage.RUNTIME.

>
> At the time of expression resolution the RuntimeExpressionResolver would
> then check the CapabilityRegistry to see if an expression resolver has been
> registered and attempt to use it falling back to vault then default
> ModelNode resolution if it does not resolve the expression.
> Using a runtime API I suspect I would likely need to trigger the
> initialisation of these APIs at the start of Stage.RUNTIME - that looks
> feasible by adding a stage to Stage.RUNTIME with addFirst test to true -
> maybe to be safe these should also start on demand based on first access.
>

I think the big problem is these runtime API objects need to access some
service and that service isn't available until the Elytron subsystem
Stage.RUNTIME steps happen, and there is no consistent ordering of those
steps vs other subsystems.

Even if parallel boot didn't exist, if a Stage.MODEL step adds a RUNTIME
step with addFirst 'true', that RUNTIME is only 'first' until some
subsequent Stage.MODEL step does the same thing.

If the runtime API objects don't rely on anything done by the elytron
subsystem in Stage.RUNTIME, then it's ok. For example if they are
instantiated with their configuration data and thereafter they just work
independently, it's ok. For the runtime API object for your 'resource
handling expression resolution' that sounds feasible. Is it feasible for
the credential stores?

Best regards,
Brian

Regards,
> Darran Lofthouse.
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190712/0a120522/attachment.html