Re: [wildfly-dev] Read Elytron security domain from Undertow's ApplicationSecurityDomainService

I have submitted the PRs as they are for now: https://github.com/wildfly/wildfly-core/pull/4276 https://github.com/wildfly/wildfly/pull/13419 But these changes are still more the beginning than the end, as I say previously I want to get to the point the DUPs collaboratively define a security policy before we enter Phase.INSTALL so during Phase.INSTALL all DUPs can install their services based on the defined policy. Two areas I am likely to follow up on are: 1. Making the application-security-domain resources optional where legacy security is not installed. 2. Further deployments such as EE security that can make use of a DUP defined security domain instead of requiring managed configuration. Regards, Darran Lofthouse. On Mon, Jul 6, 2020 at 2:21 PM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > At the moment this is the earliest I can get resolution to happen, > ideally at some point I want to pull it all the way back to somewhere > around Phase.REGISTER or Phase.FIRST_MODULE_USE at the latest. > > The final problem that I ran into was the way web services dynamically a > complete list of DeploymentUnitProcessors in a sequential block - there is > no way to interleave any other DeploymentUnitProcessors. For my resolution > to work correctly I need to be able to identify that the deployment is a > web application and we can't identify if it is a web application until > after the WS deployment processors have marked it as a web application. > > But overall the general issue seems to be that over time deployment unit > processors have been incrementally enhanced over the years with more and > more happening in Phase.INSTALL which is making coordination much much > harder > > As a starting point I think the deployment unit processors up to and > including Phase.PARSE are focussed on extracting relevant meta data from > the deployment they are handling. Before Phase.INSTALL starts all > decisions about how the deployment is defined should have already been made > allowing DeploymentUnitProcessors to get on with installing the services > for the deployment without too much additional decision making. If on > entering Phase.INSTALL all decisions have been made then ordering could be > largely irrelevant at that stage as the resulting MSC service dependencies > will define the final order of initialisation. Between Phase.PARSE and > Phase.INSTALL there are then five phases that could be used for the > coordination decisions. > > Regards, > Darran Lofthouse. > > > On Mon, Jul 6, 2020 at 1:14 PM Jim Ma <ema(a)redhat.com&gt; wrote: > >> If I understand correctly, we can only get the actual/resolved domain >> security service name from SecurityMetaData after it's resolved. >> EndpointServiceDeploymentAspect does the inject service etc and is running >> after Phase.INSTALL 0x1CFF where domain security name is resolved. Do you >> think we can resolve security domain name before >> INSTALL_WS_DEPLOYMENT_ASPECTS, like 0x1c09 ? >> >> >> * public static final int INSTALL_CDI_VALIDATOR_FACTORY >> = 0x1C02; public static final int INSTALL_WS_UNIVERSAL_META_DATA_MODEL >> = 0x1C10; public static final int INSTALL_WS_DEPLOYMENT_ASPECTS >> = 0x1C11;* >> >> On Mon, Jul 6, 2020 at 7:56 PM Darran Lofthouse < >> darran.lofthouse(a)jboss.com&gt; wrote: >> >>> On Mon, Jul 6, 2020 at 12:21 PM Jim Ma <ema(a)redhat.com&gt; wrote: >>> >>>> Hi Darran, >>>> This looks good. Please go ahead to submit pull requests. >>>> Basically we can change webservice code to pass SecurityMetaData to >>>> ElytronSecurityDomainContextImpl and finally get the Elytron >>>> SecurityDomain. Is there any Elytron utility class to get the actual >>>> Elyron SecurityDomain from a ServiceName ? >>>> >>> >>> That but shouldn't need any specific utility code, it will just be an >>> MSC service dependency allowing direct access to the security domain once >>> injected into a service. >>> >>> >>>> Thanks, >>>> Jim >>>> >>>> On Mon, Jul 6, 2020 at 4:01 PM Darran Lofthouse < >>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>> >>>>> Hello Jim, >>>>> >>>>> Just wanted to check how your early reviews of the changes have >>>>> gone? >>>>> >>>>> Long term I want to undertake a lot more work to pull security >>>>> processing as early as we can within the deployment unit processors but for >>>>> now this feels like a suitable intermediate step. If you think you can >>>>> work with this I will get the pull requests submitted against WildFly Core >>>>> and WildFly so we can make sure we get plenty of CI runs. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On Tue, Jun 9, 2020 at 9:38 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>> >>>>>> Hi Darran, >>>>>> Thanks for the update. I'll look at your change. Once this PR is >>>>>> merged, I'll start to fix this webservice issue based on your new change. >>>>>> >>>>>> Cheers, >>>>>> Jim >>>>>> >>>>>> On Mon, Jun 8, 2020 at 6:45 PM Darran Lofthouse < >>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>> >>>>>>> I have two topic branches prepared with the solution I think I can >>>>>>> make use of for now. >>>>>>> >>>>>>> There is still quite a lot of work to do but this aligns with the >>>>>>> current subsystems in WildFly. Later on and especially once we remove >>>>>>> legacy security I would like the definition of the security policy to take >>>>>>> place in earlier phases to collaboratively define the resulting security >>>>>>> policy for the deployment so at the very latest before we enter >>>>>>> Phase.INSTALL the policy is fully defined and can be used by >>>>>>> all subsystems. For the Undertow and EJB subsystems I was able to achieve >>>>>>> this during Phase.PARSE and Phase.POST_MODULE, however the web services >>>>>>> DeploymentUnitProcessors add a new web meta data in Phase.INSTALL which >>>>>>> needs to be taken into account. >>>>>>> >>>>>>> The two topic branches are: >>>>>>> >>>>>>> https://github.com/darranl/wildfly-core/tree/WFCORE-4962 >>>>>>> https://github.com/darranl/wildfly/tree/WFLY-13319 >>>>>>> >>>>>>> Unless I run into any more testing issues I believe these are now >>>>>>> complete. >>>>>>> >>>>>>> If the Elytron subsystem is installed the following will be >>>>>>> attached to the DeploymentUnit at Phase.STRUCTURE 0x2300: >>>>>>> >>>>>>> >>>>>>> https://github.com/darranl/wildfly-core/blob/WFCORE-4962/server/src/main/... >>>>>>> >>>>>>> Various DeploymentUnitProcessors interact with this metadata but if >>>>>>> an Elytron SecurityDomain is selected for the web deployment >>>>>>> the getSecurityDomain() method will return a ServiceName which can be used >>>>>>> to add a dependency to obtain a reference to it. The latest the service >>>>>>> name of the security domain will be set is Phase.INSTALL 0x1CFF. The >>>>>>> ServiceName is not set as a result of any resolution within the EJB >>>>>>> subsystem as a single deployment could contain EJBs in addition to web >>>>>>> content. This metadata is also exclusively in relation to an Elytron >>>>>>> SecurityDomain so it not set for a legacy SecurityDomain. >>>>>>> >>>>>>> Any subsystem wishing to use the resolved security domain can >>>>>>> either install a DeploymentUnitProcessor after Phase.INSTALL 0x1CFF, or >>>>>>> they can cache a reference to the SecurityMetaData instance and retrieve >>>>>>> the ServiceName at a later point. >>>>>>> >>>>>>> I am going to perform some more all tests runs locally with some >>>>>>> different permutations before I submit the PRs but I have been running into >>>>>>> some issues with the EJBInvocationStatisticsTestCase which I see is >>>>>>> currently being worked on so just waiting for that test to be more stable >>>>>>> as it keeps affecting my local builds. Other than that I believe I do have >>>>>>> all tests passing, including a new test I added to test identity >>>>>>> propagation into the EJB container when using MicroProfile JWT. >>>>>>> >>>>>>> Regards, >>>>>>> Darran Lofthouse. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 2, 2020 at 11:38 AM Darran Lofthouse < >>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>> >>>>>>>> I almost have a solution in place that I think we can use, I have >>>>>>>> just run into an issue specifically related to the web services metadata I >>>>>>>> think I can find a way past if for the changes I am specifically making but >>>>>>>> it may still make it harder to get the security domain into the web >>>>>>>> services deployment unit processor. >>>>>>>> >>>>>>>> Overall it feels like a general problem is too much security >>>>>>>> domain resolution is happening within Phase.INSTALL - this is leaving us >>>>>>>> with very little flexibility as the resulting security policy is very >>>>>>>> dependent on the relationships between the deployment unit processors in >>>>>>>> this phase occurring in the order they presently operate in. >>>>>>>> >>>>>>>> The ideal that I am trying to reach is that we clean up the >>>>>>>> security policy resolution and definition into earlier phases so we cleanly >>>>>>>> define the policy in an early phase and then apply it in the later phases, >>>>>>>> this makes us a lot less dependent on the ordering within a specific phase >>>>>>>> and IMO will give us a much cleaner solution as we will be able to define >>>>>>>> what is known about the security policy at each phase and at which phase it >>>>>>>> is safe to apply in later phases. >>>>>>>> >>>>>>>> The new JWT integration has had an impact on this but in general >>>>>>>> all resolutions for JWT can happen in Phase.PARSE. I have been able to >>>>>>>> make a change to Undertow to also pull the resolution step into >>>>>>>> Phase.PARSE. I haven't quite been able to split out EJB into a sooner >>>>>>>> Phase yet but that is already in Phase.POST_MODULE so we are before we >>>>>>>> enter Phase.INSTALL. >>>>>>>> >>>>>>>> My current problem is the Web services integration attempts to set >>>>>>>> a chosen security domain within the WebMetaDataCreatingDeploymentAspect >>>>>>>> which is executed quite late in the Phase.INSTALL from 0x1C11 or later - >>>>>>>> what I really need to look at is how to get the meta data manipulated by >>>>>>>> this deployment aspect ideally into Phase.PARSE. >>>>>>>> >>>>>>>> The end result that I am aiming for is that once we enter >>>>>>>> Phase.INSTALL if a WildFly Elytron SecurityDomain is being used for a >>>>>>>> deployment, a ServiceName which provides a reference to the SecurityDomain >>>>>>>> being used will be attached to the DeploymentUnit. Any other subsystems >>>>>>>> will then be able to add a dependency on this ServiceName and use it. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Darran Lofthouse. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, May 7, 2020 at 9:37 AM Darran Lofthouse < >>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>> >>>>>>>>> Ok, that may actually be a fraction early for the resolution to >>>>>>>>> have taken place so may need something in addition to this. >>>>>>>>> >>>>>>>>> Generally the security processing has been tied into individual >>>>>>>>> subsystems, what I need to work on as well is pulling more of these >>>>>>>>> decisions back into the PARSE phase. >>>>>>>>> >>>>>>>>> It looks to me that your deployment activity happens then in the >>>>>>>>> INSTALL phase between 0x1C11 and 0x1CFF >>>>>>>>> >>>>>>>>> I am going to be adding the new attachment to all DeploymentUnits >>>>>>>>> (Assuming the Elytron subsystem is installed) within the STRUCTURE phase so >>>>>>>>> all subsequent DUPs can make use of it / cache the reference etc,,, >>>>>>>>> However the final resolution where we identify the SecurityDomain is >>>>>>>>> happening within the UndertowDeploymentProcessor at 0x1D00. >>>>>>>>> >>>>>>>>> I think really now is going to have to be the time where I pull >>>>>>>>> some of the steps in UndertowDeploymentProcessor back to the PARSE phase, >>>>>>>>> that way you will have everything you need. >>>>>>>>> >>>>>>>>> The scope of the issue I am working on seems to have expanded a >>>>>>>>> little ;-) but this feels like it is going to contribute a lot to the next >>>>>>>>> steps to allow PicketBox to be removed from the default configuration. >>>>>>>>> >>>>>>>>> Long term for subsystems such as web services you should just be >>>>>>>>> able to pull this new SecurityMetaData attachment from the DeploymentUnit >>>>>>>>> and use that to identify the resulting policy being applied without needing >>>>>>>>> to duplicate any resolution logic performed in other subsystems. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Darran Lofthouse. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, May 7, 2020 at 3:30 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Thanks Darran. >>>>>>>>>> EndpointService[1] installed by >>>>>>>>>> EndpointServiceDeplomentAspect[2] needs to access it . The >>>>>>>>>> EndpointServiceDeployment is wrapped in AbstractDeploymentUnitProcessor[3] >>>>>>>>>> with Phase.INSTALL to deploy/undeploy. >>>>>>>>>> [1] >>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>>>>> [2] >>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>>>>> [3] >>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>>>>> >>>>>>>>>> On Wed, May 6, 2020 at 6:32 PM Darran Lofthouse < >>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Hello Jim, >>>>>>>>>>> >>>>>>>>>>> Sorry I haven't had a chance to try your reproducer but I am >>>>>>>>>>> currently debugging another issue and I think the solution for this issue >>>>>>>>>>> may actually help with the problem you are having. >>>>>>>>>>> >>>>>>>>>>> https://issues.redhat.com/browse/WFLY-13319 >>>>>>>>>>> >>>>>>>>>>> In the case I am looking into the EJB deployment unit >>>>>>>>>>> processors are being executed before it has been determined, I have been >>>>>>>>>>> considering whether I could tweak the order of one of the DUPs but that is >>>>>>>>>>> not possible due to the dependencies so I need another solution anyway. >>>>>>>>>>> >>>>>>>>>>> What I am presently thinking is during the Phase.STRUCTURE I >>>>>>>>>>> could add an empty "SecurityMetaData" object as an attachment to the >>>>>>>>>>> DeploymentUnit, initially this will just contain a single value which will >>>>>>>>>>> be the ServiceName of the Elytron SecurityDomain to use and will default to >>>>>>>>>>> "null". >>>>>>>>>>> >>>>>>>>>>> The first DeploymentUnitProcessor to identify that an Elytron >>>>>>>>>>> SecurityDomain is to be used will then set the ServiceName of the >>>>>>>>>>> SecurityDomain to use. >>>>>>>>>>> >>>>>>>>>>> Longer term we will be removing the application-security-domain >>>>>>>>>>> resources as they were just to enable coexistence with legacy security so >>>>>>>>>>> at some point in the future deployments will either be secured using >>>>>>>>>>> Elytron or will be unsecured and having a common SecurityMetaData can act >>>>>>>>>>> as the shared base for the future. >>>>>>>>>>> >>>>>>>>>>> Can you please confirm from which of the Web Services >>>>>>>>>>> DeploymentUnitProcessors you need access to this, we will probably need to >>>>>>>>>>> double check if any other checks need pulling further forward, so far we >>>>>>>>>>> have one happens in Phase.PARSE, one in Phase.POST, and one in >>>>>>>>>>> Phase.INSTALL. Ideally long term we will pull all of this identification >>>>>>>>>>> back to Phase.PARSE. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Darran Lofthouse. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, May 6, 2020 at 8:10 AM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Darran, >>>>>>>>>>>> Did you get time to look at this reproducer? Any findings ? >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jim >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Apr 2, 2020 at 2:00 PM Jim Ma <ema(a)redhat.com&gt; wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks Darran. I uploaded the war deployment and reproduce >>>>>>>>>>>>> steps readme to >>>>>>>>>>>>> https://github.com/jimma/elytron-null-securitydomain. >>>>>>>>>>>>> Let me know if this helps to debug why the SecurityDomain is >>>>>>>>>>>>> not associated. >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Apr 2, 2020 at 12:33 AM Darran Lofthouse < >>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> TBH Jim, I think I would need to dig into the code with a >>>>>>>>>>>>>> debugger to double check what is happening there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> SecurityDomain.getCurrent() will return null when no >>>>>>>>>>>>>> SecurityDomain is associated with the deployment, the >>>>>>>>>>>>>> DeploymentUnitProcessor added for the Elytron integration essentially >>>>>>>>>>>>>> checks what SecurityDomain name Undertow was going to use and then checks >>>>>>>>>>>>>> if it should swap in an Elytron SecurityDomain instead. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If SecurityDomain association is being skipped due to the >>>>>>>>>>>>>> lack of a security-constraint we should probably revisit that as there are >>>>>>>>>>>>>> plenty of scenarios where association of a SecurityDomain would make sense >>>>>>>>>>>>>> even if the constraints are not defined in the web.xml. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Apr 1, 2020 at 11:29 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Darran, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The SecurityDomain.getCurrent() returns null when there is >>>>>>>>>>>>>>> "other" security domain in jboss-web.xml and no “security-constraint” >>>>>>>>>>>>>>> defined in web.xml like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------------jboss-web.xml--------------------- >>>>>>>>>>>>>>> <jboss-web> >>>>>>>>>>>>>>> <security-domain>other</security-domain> >>>>>>>>>>>>>>> </jboss-web> >>>>>>>>>>>>>>> --------------web.xml------------------------------ >>>>>>>>>>>>>>> <web-app >>>>>>>>>>>>>>> version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" >>>>>>>>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>>>>>>>>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >>>>>>>>>>>>>>> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"> >>>>>>>>>>>>>>> <servlet> >>>>>>>>>>>>>>> <servlet-name>TestService</servlet-name> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <servlet-class>org.jboss.test.ws.jaxws.samples.wsse.policy.jaas.ServiceImpl</servlet-class> >>>>>>>>>>>>>>> </servlet> >>>>>>>>>>>>>>> <servlet-mapping> >>>>>>>>>>>>>>> <servlet-name>TestService</servlet-name> >>>>>>>>>>>>>>> <url-pattern>/*</url-pattern> >>>>>>>>>>>>>>> </servlet-mapping> >>>>>>>>>>>>>>> </web-app> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this mean Elytron security domain mapped by undertow >>>>>>>>>>>>>>> "other" application domain only is enforced/set for web deployment which >>>>>>>>>>>>>>> contains <security-constraint>deployment descriptor ? >>>>>>>>>>>>>>> When does SecurityDomain.getCurrent() return null value ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Jim >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:35 PM Darran Lofthouse < >>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes there should be no difference at runtime, if we >>>>>>>>>>>>>>>> identified the Elytron domain via the default security domain it should >>>>>>>>>>>>>>>> still be associated with the deployment in the same way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 10:33 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Will this work for Undertow default "other" application >>>>>>>>>>>>>>>>> security domain's reference Elytron SecurityDomain ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:26 PM Darran Lofthouse < >>>>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Overall it is the SecurityDomain.getCurrent method you >>>>>>>>>>>>>>>>>> need: - >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://wildfly-security.github.io/wildfly-elytron/master-public/org/wild... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If a SecurityDomain is associated with the Thread's >>>>>>>>>>>>>>>>>> context class loader it will be returned. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 10:22 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Mon, Mar 16, 2020 at 6:07 PM Darran Lofthouse < >>>>>>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I don't know if it will help but the SecurityDomain is >>>>>>>>>>>>>>>>>>>> associated with the ClassLoader of the deployment, not sure if that could >>>>>>>>>>>>>>>>>>>> be an alternative way for WS to access it. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'll try it . Can you please point me some code >>>>>>>>>>>>>>>>>>> example or test code? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> The thing that is complicating it for now is the dual >>>>>>>>>>>>>>>>>>>> mode with PicketBox, once we remove PicketBox a deployment will either have >>>>>>>>>>>>>>>>>>>> an Elytron SecurityDomain or it will not. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yes. Now webservice has to add many PicketBox or >>>>>>>>>>>>>>>>>>> Elytron checks to do following actions. We wrap this as much as possible >>>>>>>>>>>>>>>>>>> with spi interface. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Mar 13, 2020 at 8:20 AM Jim Ma <ema(a)redhat.com&gt; >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 8:12 PM Darran Lofthouse < >>>>>>>>>>>>>>>>>>>>> darran.lofthouse(a)jboss.com&gt; wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Is it possible to identify the revelevent >>>>>>>>>>>>>>>>>>>>>> DeploymentUnitProcessors in this process along with their phase and >>>>>>>>>>>>>>>>>>>>>> priority so we can check the ordering. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The "other"'s mapped Elytron security domain service >>>>>>>>>>>>>>>>>>>>> is required to read in EndpointServiceDeploymentAspect. It's installed >>>>>>>>>>>>>>>>>>>>> in Phase.INSTALL, Phase.INSTALL_WS_DEPLOYMENT_ASPECTS priority. It's >>>>>>>>>>>>>>>>>>>>> running before UndertowDeploymentProcessor >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> What may be more appropriate is for the Undertow DUP >>>>>>>>>>>>>>>>>>>>>> to attach something which identifies the SecurityDomain instead of the web >>>>>>>>>>>>>>>>>>>>>> services DUP relying on internal API / repeating the same checks already >>>>>>>>>>>>>>>>>>>>>> performed within Undertow. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> In the future we will be removing all of the >>>>>>>>>>>>>>>>>>>>>> application security domain resources so coordinating using attachments >>>>>>>>>>>>>>>>>>>>>> will hopefully also future proof any fix. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It looks this attachment should be set in some >>>>>>>>>>>>>>>>>>>>> Undertow DUP before UndertowDeploymentProcessor. WebService needs a >>>>>>>>>>>>>>>>>>>>> Securitycontext to call the ejb ws endpoint method or webservice endpoint >>>>>>>>>>>>>>>>>>>>> method : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... >>>>>>>>>>>>>>>>>>>>> Is there better api/approach to perform this kind of >>>>>>>>>>>>>>>>>>>>> method invocation ? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Jim >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Darran Lofthouse. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Mar 12, 2020 at 11:45 AM Jim Ma < >>>>>>>>>>>>>>>>>>>>>> ema(a)redhat.com&gt; wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> There is ws deployment failure issue[1] which is >>>>>>>>>>>>>>>>>>>>>>> caused by Webservice subsystem doesn't correctly get mapped elytron >>>>>>>>>>>>>>>>>>>>>>> security domain from web deployment's default "other" >>>>>>>>>>>>>>>>>>>>>>> application security domain. I tried to fix this by >>>>>>>>>>>>>>>>>>>>>>> reading Elytron security domain from Undertow started services, but it >>>>>>>>>>>>>>>>>>>>>>> looks now ApplicationSecurityDomainService is private static and it doesn't >>>>>>>>>>>>>>>>>>>>>>> provide a getter which allows to get Elytron security domain. Webservice >>>>>>>>>>>>>>>>>>>>>>> subsystem requires an Undertow service like >>>>>>>>>>>>>>>>>>>>>>> ApplicationSecurityDomainService[2] started by EJB subsystem to read the >>>>>>>>>>>>>>>>>>>>>>> Elytron security domain. Is it doable to change >>>>>>>>>>>>>>>>>>>>>>> Undertow's ApplicationSecurityDomainService to provide mapped security >>>>>>>>>>>>>>>>>>>>>>> domain ? Or any better approach to get the mapped Elytron domain ? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> [1]https://issues.redhat.com/browse/WFLY-12765 >>>>>>>>>>>>>>>>>>>>>>> [2] >>>>>>>>>>>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>> Jim >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> wildfly-dev mailing list >>>>>>>>>>>>>>>>>>>>>>> wildfly-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>