[
https://issues.jboss.org/browse/WFLY-11137?page=com.atlassian.jira.plugin...
]
Yeray Borges commented on WFLY-11137:
-------------------------------------
org.jboss.as.security and org.picketbox are optional if we assume the legacy-security
subsystem is disabled, the default security domain (other) is not mapped to an Elytron
capability and the application we are deploying is not using a security domain or any
authentication/authorization services.
Makes sense to me make both optional for such case, so I'm going to create a PR
allowing both optional, [~brian.stansberry] let me know if you have a different opinion.
We could make org.jboss.security.negotiation optional if we were able to configure the
SPNEGO authentication mechanism via servlet-container in undertow subsystem, but right now
this mechanism is always added. I understand we will need a different issue to address
it.
Make undertow extension module's dependency on
org.jboss.as.security module optional
------------------------------------------------------------------------------------
Key: WFLY-11137
URL:
https://issues.jboss.org/browse/WFLY-11137
Project: WildFly
Issue Type: Task
Components: Security, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Yeray Borges
Priority: Major
Don't require the legacy security subsystem module if it's not actually used.
Usage looks like this:
{code}
wildfly bstansberry$ cd undertow/
undertow bstansberry$ git grep org.jboss.as.security
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentInfoService.java:import
org.jboss.as.security.plugins.SecurityDomainContext;
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import
org.jboss.as.security.deployment.AbstractSecurityDeployer;
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import
org.jboss.as.security.deployment.SecurityAttachments;
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import
org.jboss.as.security.plugins.SecurityDomainContext;
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import
org.jboss.as.security.service.JaccService;
src/main/java/org/wildfly/extension/undertow/deployment/UndertowDeploymentProcessor.java:import
org.jboss.as.security.service.SecurityDomainService;
src/main/java/org/wildfly/extension/undertow/security/DigestCredentialImpl.java:import
org.jboss.as.security.DigestCredential;
src/main/java/org/wildfly/extension/undertow/security/JAASIdentityManagerImpl.java:import
org.jboss.as.security.plugins.SecurityDomainContext;
src/main/java/org/wildfly/extension/undertow/security/SecurityContextThreadSetupAction.java:import
org.jboss.as.security.plugins.SecurityDomainContext;
src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import
org.jboss.as.security.deployment.AbstractSecurityDeployer;
src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCDeployer.java:import
org.jboss.as.security.service.JaccService;
src/main/java/org/wildfly/extension/undertow/security/jacc/WarJACCService.java:import
org.jboss.as.security.service.JaccService;
{code}
Dropping the use of SecurityAttachments from UndertowDeploymentProcessor and instead
having it check for the presence of the org.wildfly.legacy-security capability will go a
long way here. After that, most if not all of the other uses only get called either as a
result of that check being true, or some config attribute that directly or indirectly
references a security domain. IOW the other uses are only needed if the security subsystem
is known to be configured.
Per Intellij, DigestCredentialImpl is unused.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)