Details
-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
Undefined
-
---
-
---
Description
Currently if the legacy security subsystem is not present in the config, users who wish to include a resource adapter in the config need to add a lot of boilerplate to the r-a configuration just to get the subsystem to not try and add in dependencies on non-existent legacy security services.
Here's an example r-a config in the standalone.xml we use for the EE 9 TCK:
<resource-adapter id="whitebox-permissiondd.rar"> <archive>whitebox-permissiondd.rar</archive> <workmanager> </workmanager> <connection-definitions> <connection-definition jndi-name="java:/eis/whitebox-permissiondd" class-name="com.sun.ts.tests.common.connector.whitebox.permissiondd.PermissionDDMCF" pool-name="wb-permissiondd-connection"> <security> <elytron-enabled>true</elytron-enabled> </security> <recovery> <recover-credential> <elytron-enabled>true</elytron-enabled> </recover-credential> </recovery> <pool> <max-pool-size>1000</max-pool-size> </pool> </connection-definition> </connection-definitions> </resource-adapter>
We need to make this easier. WildFly Preview doesn't offer legacy security, and by WildFly 24, next spring, the standard configs in regular WF won't either.
I'm deliberately being vague here as I haven't thought through precisely what should change. That is best discussed with the security team. My main thought is the subsystem can check a capability and thus know whether legacy security is present in the config. If it's not, and the user hasn't explicitly configured something that indicates they want legacy security, then we should set things up in a way that doesn't require it.