WildFly Elytron - Credential Store - Next Stages

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

WildFly Elytron - Credential Store - Next Stages

Darran Lofthouse
During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.

We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.

I have put together a blog post describing some of the general issues we want to look into: -


Some of these changes will have an impact on any subsystem currently referencing the credential store.

Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.

I am also going to share this link in the community forums to try and obtain some additional feedback from end users.

Regards,
Darran Lofthouse.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Jean-Francois Denise

Hi Darran,

looking at "Automation of Updates to the Store" in which CLI could be involved, I am listing potential issues if the CLI handles it:

- it seems that the clear=>store+alias could be on a per operation basis. User could still want to not rely on credential store. So enabling globally the transformation would not work.

- Having an interactive workflow would not work well for scripts.

- Introducing new headers dedicated to automatic conversion  could work (they would have to be recognized and support implemented on server), although with multiple credential-references located in the same command, the syntax could become complex.

After having played a bit with CLI+credential-references, I am thinking that defining a new attribute in the credential-reference (existing clear-text and store are alternatives, can't use both) to express that the user wants automatic storage would seem quite natural from CLI. Furthermore, it would work with CLI existing support for operations.

Something like {clear-text=mypassword, update-store=mystore, alias=ALIAS} I would enforce that the update-store already exists.

If that is possible in elytron subsystem, that would make for a simple CLI workflow.

JF

On 26/09/2018 15:15, Darran Lofthouse wrote:
During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.

We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.

I have put together a blog post describing some of the general issues we want to look into: -


Some of these changes will have an impact on any subsystem currently referencing the credential store.

Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.

I am also going to share this link in the community forums to try and obtain some additional feedback from end users.

Regards,
Darran Lofthouse.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Darran Lofthouse
On Tue, Nov 27, 2018 at 2:46 PM Jean-Francois Denise <[hidden email]> wrote:

Hi Darran,

looking at "Automation of Updates to the Store" in which CLI could be involved, I am listing potential issues if the CLI handles it:

- it seems that the clear=>store+alias could be on a per operation basis. User could still want to not rely on credential store. So enabling globally the transformation would not work.


I suspect it would be more a case of if they specify all three attributes we would automatically take the clear password and store it in the referenced credential store using the specified alias.  Trying to automatically select a credential store and generate an alias seems more trouble than it would be worth,
 

- Having an interactive workflow would not work well for scripts.

- Introducing new headers dedicated to automatic conversion  could work (they would have to be recognized and support implemented on server), although with multiple credential-references located in the same command, the syntax could become complex.

After having played a bit with CLI+credential-references, I am thinking that defining a new attribute in the credential-reference (existing clear-text and store are alternatives, can't use both) to express that the user wants automatic storage would seem quite natural from CLI. Furthermore, it would work with CLI existing support for operations.

Something like {clear-text=mypassword, update-store=mystore, alias=ALIAS} I would enforce that the update-store already exists.

If that is possible in elytron subsystem, that would make for a simple CLI workflow.

JF

On 26/09/2018 15:15, Darran Lofthouse wrote:
During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.

We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.

I have put together a blog post describing some of the general issues we want to look into: -


Some of these changes will have an impact on any subsystem currently referencing the credential store.

Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.

I am also going to share this link in the community forums to try and obtain some additional feedback from end users.

Regards,
Darran Lofthouse.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Martin Choma
In reply to this post by Darran Lofthouse
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.
  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:

>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Brian Stansberry


On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <[hidden email]> wrote:
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.

This is certainly something to consider when considering any new management functionality.

Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.

I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P.  On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.

I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)

  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:
>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Darran Lofthouse-2

On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <[hidden email]> wrote:


On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <[hidden email]> wrote:
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.

This is certainly something to consider when considering any new management functionality.

Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.

Yes the real time updates could only ever be approached on a resource by resource basis so existing resources (at least we have a finite set to consider) would either need to already update real time password updates or be retrospectively modified to support them - for the credential store the best we can do it make this a possibility.
 
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.

I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P.  On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.

I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)

Rather than focusing on the management side of the credential store and features like real time updates it feels to me that emphasis should be on this username / password problem - any enhancements in this area having a better chance for long term relevance.

As I have mentioned previously we know we have some resources that only require a credential, such as unlocking a local KeyStore.

The username / password pairing is a common issue - we don't really have a clean solution for this yet so would be a good area to focus.

However a number of newer authentication mechanisms have moved beyond the traditional username / password combo, some need an alternative to a password, some don't need a username at all.  These also often have an option to delegate the callers identity to the remote endpoint etc...

Better solving these last two would seem to be a better investment of effort, regardless of how static future configurations do or do not become this would still be relevant.

We already have the client side authentication context which provides a very flexible configuration selection approach based on the endpoint being connected to and additional information available as the connection is requested.  Whilst very flexible this does add a level of complexity in understanding how the configuration is assembled and how mappings are applied.

The next resource we have is the existing authentication-configuration, this is effectively a single client side authentication policy for an outbound connection.  

I think from an end users perspective it is clearer to visualise a 1:1 relationship between the resource defining the outbound connection and the resource defining the authentication policy.  From a tooling perspective as these are linked by capabilities a user doesn't even need to fully see the separation, e.g. as you edited a datasource the console could offer an option to edit the authentication-configuration which could open without forcing the user to navigate to a different location in the model hierarchy.

We would need to look into more detail as to the suitability of this resource and exactly how we would integrate it but this would generally be my preferred starting point over trying to replicate expression expansion.
 

  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:
>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Darran Lofthouse-2
Following on from my last e-mail this brings us to a follow on step for the users that are looking to externalise both their username and credential configuration together.

Within the Elytron subsystem I can now add a new 'authentication-client-file' resource to load static definitions from file, as static definitions these will not be manageable.  By using child resources however I can still hook these into capabilities to make them referenceable.

By loading from file we could also consider a couple of additional options such as encrypting the file, we could also consider bundling within a jar allowing other resources such as keytabs and certificates to be bundled with the configuration.

After this stage we then have further possibilities to expand on this further.

We could add a custom authentication-client resolver SPI to allow for custom resolvers, anyone who wants to resolve from custom locations could add their own implementation.  In hosted environments such as OpenShift custom resolvers could be used to obtain authentication policies being managed elsewhere without relying on property expansion.

Additionally by having all of this wrapped in an API we have the ability to add both auditing and authorization for anything accessing this configuration - something that is not possible in solutions that rely on expression expansion.

Regards,
Darran Lofthouse.



On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <[hidden email] wrote:

On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <[hidden email]> wrote:


On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <[hidden email]> wrote:
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.

This is certainly something to consider when considering any new management functionality.

Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.

Yes the real time updates could only ever be approached on a resource by resource basis so existing resources (at least we have a finite set to consider) would either need to already update real time password updates or be retrospectively modified to support them - for the credential store the best we can do it make this a possibility.
 
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.

I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P.  On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.

I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)

Rather than focusing on the management side of the credential store and features like real time updates it feels to me that emphasis should be on this username / password problem - any enhancements in this area having a better chance for long term relevance.

As I have mentioned previously we know we have some resources that only require a credential, such as unlocking a local KeyStore.

The username / password pairing is a common issue - we don't really have a clean solution for this yet so would be a good area to focus.

However a number of newer authentication mechanisms have moved beyond the traditional username / password combo, some need an alternative to a password, some don't need a username at all.  These also often have an option to delegate the callers identity to the remote endpoint etc...

Better solving these last two would seem to be a better investment of effort, regardless of how static future configurations do or do not become this would still be relevant.

We already have the client side authentication context which provides a very flexible configuration selection approach based on the endpoint being connected to and additional information available as the connection is requested.  Whilst very flexible this does add a level of complexity in understanding how the configuration is assembled and how mappings are applied.

The next resource we have is the existing authentication-configuration, this is effectively a single client side authentication policy for an outbound connection.  

I think from an end users perspective it is clearer to visualise a 1:1 relationship between the resource defining the outbound connection and the resource defining the authentication policy.  From a tooling perspective as these are linked by capabilities a user doesn't even need to fully see the separation, e.g. as you edited a datasource the console could offer an option to edit the authentication-configuration which could open without forcing the user to navigate to a different location in the model hierarchy.

We would need to look into more detail as to the suitability of this resource and exactly how we would integrate it but this would generally be my preferred starting point over trying to replicate expression expansion.
 

  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:
>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Brian Stansberry
Sorry for the slow reply.

This last post sounds quite a bit like the vault. But with an updated API/SPI and a much richer possible set of behavior. And instead of using expression resolution for access, which has the negative of making it theoretically usable for pretty much any attribute, but with the system not really knowing how it is being used, there is proper capability-based integration. Is that a fair read on this?

On Fri, Dec 7, 2018 at 7:16 AM Darran Lofthouse <[hidden email]> wrote:
Following on from my last e-mail this brings us to a follow on step for the users that are looking to externalise both their username and credential configuration together.

Within the Elytron subsystem I can now add a new 'authentication-client-file' resource to load static definitions from file, as static definitions these will not be manageable.  By using child resources however I can still hook these into capabilities to make them referenceable.

By loading from file we could also consider a couple of additional options such as encrypting the file, we could also consider bundling within a jar allowing other resources such as keytabs and certificates to be bundled with the configuration.

After this stage we then have further possibilities to expand on this further.

We could add a custom authentication-client resolver SPI to allow for custom resolvers, anyone who wants to resolve from custom locations could add their own implementation.  In hosted environments such as OpenShift custom resolvers could be used to obtain authentication policies being managed elsewhere without relying on property expansion.

Additionally by having all of this wrapped in an API we have the ability to add both auditing and authorization for anything accessing this configuration - something that is not possible in solutions that rely on expression expansion.

Regards,
Darran Lofthouse.



On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <[hidden email] wrote:

On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <[hidden email]> wrote:


On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <[hidden email]> wrote:
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.

This is certainly something to consider when considering any new management functionality.

Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.

Yes the real time updates could only ever be approached on a resource by resource basis so existing resources (at least we have a finite set to consider) would either need to already update real time password updates or be retrospectively modified to support them - for the credential store the best we can do it make this a possibility.
 
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.

I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P.  On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.

I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)

Rather than focusing on the management side of the credential store and features like real time updates it feels to me that emphasis should be on this username / password problem - any enhancements in this area having a better chance for long term relevance.

As I have mentioned previously we know we have some resources that only require a credential, such as unlocking a local KeyStore.

The username / password pairing is a common issue - we don't really have a clean solution for this yet so would be a good area to focus.

However a number of newer authentication mechanisms have moved beyond the traditional username / password combo, some need an alternative to a password, some don't need a username at all.  These also often have an option to delegate the callers identity to the remote endpoint etc...

Better solving these last two would seem to be a better investment of effort, regardless of how static future configurations do or do not become this would still be relevant.

We already have the client side authentication context which provides a very flexible configuration selection approach based on the endpoint being connected to and additional information available as the connection is requested.  Whilst very flexible this does add a level of complexity in understanding how the configuration is assembled and how mappings are applied.

The next resource we have is the existing authentication-configuration, this is effectively a single client side authentication policy for an outbound connection.  

I think from an end users perspective it is clearer to visualise a 1:1 relationship between the resource defining the outbound connection and the resource defining the authentication policy.  From a tooling perspective as these are linked by capabilities a user doesn't even need to fully see the separation, e.g. as you edited a datasource the console could offer an option to edit the authentication-configuration which could open without forcing the user to navigate to a different location in the model hierarchy.

We would need to look into more detail as to the suitability of this resource and exactly how we would integrate it but this would generally be my preferred starting point over trying to replicate expression expansion.
 

  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:
>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Elytron - Credential Store - Next Stages

Darran Lofthouse-2
Hi Brian.

I think approximately yes, the vault was intended for storing passwords then was used for storing other things as well, the credential store is the evolution of the vault but is truly about passwords only.  The next stage I am proposing is a complete client side authentication policy which achieves the pairing that went into the vault but also an awful lot more.

Regards,
Darran Lofthouse.


On Tue, Dec 18, 2018 at 9:51 PM Brian Stansberry <[hidden email]> wrote:
Sorry for the slow reply.

This last post sounds quite a bit like the vault. But with an updated API/SPI and a much richer possible set of behavior. And instead of using expression resolution for access, which has the negative of making it theoretically usable for pretty much any attribute, but with the system not really knowing how it is being used, there is proper capability-based integration. Is that a fair read on this?

On Fri, Dec 7, 2018 at 7:16 AM Darran Lofthouse <[hidden email]> wrote:
Following on from my last e-mail this brings us to a follow on step for the users that are looking to externalise both their username and credential configuration together.

Within the Elytron subsystem I can now add a new 'authentication-client-file' resource to load static definitions from file, as static definitions these will not be manageable.  By using child resources however I can still hook these into capabilities to make them referenceable.

By loading from file we could also consider a couple of additional options such as encrypting the file, we could also consider bundling within a jar allowing other resources such as keytabs and certificates to be bundled with the configuration.

After this stage we then have further possibilities to expand on this further.

We could add a custom authentication-client resolver SPI to allow for custom resolvers, anyone who wants to resolve from custom locations could add their own implementation.  In hosted environments such as OpenShift custom resolvers could be used to obtain authentication policies being managed elsewhere without relying on property expansion.

Additionally by having all of this wrapped in an API we have the ability to add both auditing and authorization for anything accessing this configuration - something that is not possible in solutions that rely on expression expansion.

Regards,
Darran Lofthouse.



On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <[hidden email] wrote:

On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <[hidden email]> wrote:


On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <[hidden email]> wrote:
A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.

This is certainly something to consider when considering any new management functionality.

Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.

Yes the real time updates could only ever be approached on a resource by resource basis so existing resources (at least we have a finite set to consider) would either need to already update real time password updates or be retrospectively modified to support them - for the credential store the best we can do it make this a possibility.
 
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.

I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P.  On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.

I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)

Rather than focusing on the management side of the credential store and features like real time updates it feels to me that emphasis should be on this username / password problem - any enhancements in this area having a better chance for long term relevance.

As I have mentioned previously we know we have some resources that only require a credential, such as unlocking a local KeyStore.

The username / password pairing is a common issue - we don't really have a clean solution for this yet so would be a good area to focus.

However a number of newer authentication mechanisms have moved beyond the traditional username / password combo, some need an alternative to a password, some don't need a username at all.  These also often have an option to delegate the callers identity to the remote endpoint etc...

Better solving these last two would seem to be a better investment of effort, regardless of how static future configurations do or do not become this would still be relevant.

We already have the client side authentication context which provides a very flexible configuration selection approach based on the endpoint being connected to and additional information available as the connection is requested.  Whilst very flexible this does add a level of complexity in understanding how the configuration is assembled and how mappings are applied.

The next resource we have is the existing authentication-configuration, this is effectively a single client side authentication policy for an outbound connection.  

I think from an end users perspective it is clearer to visualise a 1:1 relationship between the resource defining the outbound connection and the resource defining the authentication policy.  From a tooling perspective as these are linked by capabilities a user doesn't even need to fully see the separation, e.g. as you edited a datasource the console could offer an option to edit the authentication-configuration which could open without forcing the user to navigate to a different location in the model hierarchy.

We would need to look into more detail as to the suitability of this resource and exactly how we would integrate it but this would generally be my preferred starting point over trying to replicate expression expansion.
 

  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<[hidden email]> wrote:
>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.
>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev