[
https://issues.redhat.com/browse/WFLY-13928?page=com.atlassian.jira.plugi...
]
Darran Lofthouse commented on WFLY-13928:
-----------------------------------------
[~brian.stansberry] Actually we do have an existing Jira issue for the correct approach to
identify the Elytron security domain to use but it will require some refactoring of the
web services deployment unit processors.
Overall I don't want us to be repeating the logic to resolve the security domain
across multiple subsystems, once logic is duplicated we have the overhead of maintaining
it in multiple locations and the risk they will subtly get out of sync.
Instead I want us to move to a collaborative approach where prior to entering
Phase.INSTALL subsystems collaboratively build up a security policy which will be recorded
in this attachment:
org.jboss.as.server.security.SecurityMetaData
By the time we enter Phase.INSTALL the policy should be complete and all DUPs regardless
of the order they are executed should make use of the agreed policy, no exceptions, no
further modifications. Should the SecurityMetaData not be present or not be populated
then the deployment is using legacy security which is the block of code destined to be
deleted in the future.
The one issue that we do have that has prevented reaching this objective so far is within
the (effectively single DUP) block of web services DUPs the deployment gets marked as a
web application quite late in Phase.INSTALL. This then has a knock on effect that web
application security domain resolution can't be triggered until we know the deployment
is a web application. For all other test cases in the testsuite it has been possible to
pull the web application security domain resolution all the way to I believe it was the
Configure Module phase.
We don't really have clear documentation of the expectations of the Phases, the
Javadoc seems to have been started and where we can derive information from the names it
is more in relation which class loaders are available rather than the expectations of each
phase - but overall as Phase.INSTALL is effectively the final phase where everything is
installed to be cleaner decisions should have been made before entering this phase.
I think this is a side effect of a phased architecture as well, as subsequent
modifications are made you tend to ask the question "What does this need to be
after?" and "What does this need to be before?" - this has a tendency to
push subsequent insertions later into the chain.
EndpointService should determine if a security-domain is elytron or
legacy using capabilities, not MSC
------------------------------------------------------------------------------------------------------
Key: WFLY-13928
URL:
https://issues.redhat.com/browse/WFLY-13928
Project: WildFly
Issue Type: Task
Components: Web Services
Reporter: Brian Stansberry
Assignee: Jim Ma
Priority: Minor
This is a follow on to
https://github.com/wildfly/wildfly/pull/13597/files
EndpointService's isElytronSecurityDomain and isLegacySecurityDomain are checking if
things are present by doing MSC service lookups. Generally that's unreliable; but it
works in this case because all subsystems install their services before deployment
processing begins, and EndpointService is part of deployment processing.
Still, the services that are being looked up are associated with a capability. So these
methods can just use CapabilityServiceSupport.hasCapability to see if that capability is
present.
Semi-related, in various places related to security domain integration EndpointService is
using different strategies for creating a ServiceName for the security-related service.
Some of those would be eliminated by the main change I discuss above. The others should
consolidate on using CapabilityServiceSupport. getCapabilityServiceName.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)