[wildfly-dev] Re: Disabling Legacy Security Realms

Also thinking about this, the vault configuration has the same issue in that it is a part of the core management model. I think it's "test condition" should be different but that sounds like it should also follow the same solution for now - i.e. allow the model representation to remain but disable the runtime implementation with appropriate warnings.

On Wed, Apr 21, 2021 at 9:22 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > On Tue, Apr 20, 2021 at 11:47 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Can the add handler just fail in this situation? >> >> If the elements are going to be in the XSD but not work, it seems more >> consistent to have them be in the management API and not work. >> > > That may be better for WildFly 24 as a smaller step but I don't know if > it will lead to false assumption that these resources are still supported, > also although the CLI scripts and configuration may "work" the moment > something in the model references these realms it would fail as the > required service would not be available. > > It will probably still need a generous set of warnings if we see this. > > >> Otherwise you get odd disconnects, like CLI scripts failing with >> unhelpful generic explanations about resource types not existing. Then if >> people look at the xsd they see the documentation, or they look in >> wildscribe and see it. Confusing, whereas a failure with a clear >> explanation is clear. >> > > I think documentation, wildscribe, and xsd would need some verbose > updates to identify that these resources are not usable in the situations > we describe. > > >> >> For sure we don't want the parser ignoring these elements with just a >> warn. >> > > Overall the end stage we are working towards is that these resources as > well as any attributes that reference these resources will be completely > removed from the next versions of the management models (domain management, > remoting, undertow, ...) > > So for now we will preserve the model and just disable the implementation > where it is not supported / available. > > >> >> On Tue, Apr 20, 2021 at 7:39 AM Darran Lofthouse < >> darran.lofthouse(a)jboss.com&gt; wrote: >> >>> In preparation for the eventual removal of the legacy security realms I >>> would like to first reach an intermediate state where their use can be >>> disabled. >>> >>> Disabling the use of a subsystem is fairly easy, if we omit the jars >>> containing the extension and don't register the extension then the >>> subsystem is unavailable. The legacy security realms are a little >>> different as they are a part of core. >>> >>> I think there are two situations I would like to disable them: >>> >>> - Provisioned configurations where they are disabled. >>> - Certain environments e.g. Java 17 >>> >>> For the former I can easily do something like ServiceLoader discovery >>> or Class.forName to detect if required classes have been provisioned or >>> not, for the latter I can check the Java version at runtime, >>> >>> I would propose that in the disabled cases the resources are just not >>> registered in the management model at all. These are not a >>> transformed resource so nothing special to consider there. For the XML >>> parsing if the legacy security realms are found in the configuration I >>> would then log an error to indicate they have been disabled and abort the >>> boot process. >>> >>> Technically it feels achievable, the only piece really that is not >>> accurate is the XML schema for management would still show these as valid >>> elements. Alternatively I could log a warning and ignore these elements >>> but that feels like it may cause more issues as users would be expecting >>> them to be handled and any future writes to the configuration would drop >>> them anyway. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> If I am writing outside of normal office hours, it is my choice; you do >> not need to do the same >> >