<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 1:14 PM Jim Ma <<a href="mailto:ema@redhat.com">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> 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 ?<div><font size="1"><i> public static final int INSTALL_CDI_VALIDATOR_FACTORY = 0x1C02;<br> public static final int INSTALL_WS_UNIVERSAL_META_DATA_MODEL = 0x1C10;<br> public static final int INSTALL_WS_DEPLOYMENT_ASPECTS = 0x1C11;</i></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 7:56 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jul 6, 2020 at 12:21 PM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Darran, <div>This looks good. Please go ahead to submit pull requests. </div><div>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 ? </div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks,</div><div>Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 4:01 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Jim,<div><br></div><div>Just wanted to check how your early reviews of the changes have gone? </div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 9:38 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Darran, <div>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. </div><div><br></div><div>Cheers,</div><div>Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 8, 2020 at 6:45 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have two topic branches prepared with the solution I think I can make use of for now.<div><br></div><div>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.</div><div><br></div><div>The two topic branches are: </div><div><br></div><div><a href="https://github.com/darranl/wildfly-core/tree/WFCORE-4962" target="_blank">https://github.com/darranl/wildfly-core/tree/WFCORE-4962</a><br></div><div><a href="https://github.com/darranl/wildfly/tree/WFLY-13319" target="_blank">https://github.com/darranl/wildfly/tree/WFLY-13319</a><br></div><div><br></div><div>Unless I run into any more testing issues I believe these are now complete.</div><div><br></div><div>If the Elytron subsystem is installed the following will be attached to the DeploymentUnit at Phase.STRUCTURE 0x2300:</div><div><br></div><div><a href="https://github.com/darranl/wildfly-core/blob/WFCORE-4962/server/src/main/java/org/jboss/as/server/security/SecurityMetaData.java" target="_blank">https://github.com/darranl/wildfly-core/blob/WFCORE-4962/server/src/main/java/org/jboss/as/server/security/SecurityMetaData.java</a><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 11:38 AM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 9:37 AM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ok, that may actually be a fraction early for the resolution to have taken place so may need something in addition to this.<div><br></div><div>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.</div><div><br></div><div>It looks to me that your deployment activity happens then in the INSTALL phase between 0x1C11 and 0x1CFF</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 3:30 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Darran. <div>EndpointService[1] installed by EndpointServiceDeplomentAspect[2] needs to access it . The EndpointServiceDeployment is wrapped in AbstractDeploymentUnitProcessor[3] with Phase.INSTALL to deploy/undeploy. <br><div>[1] <a href="https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java" target="_blank">https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java</a></div><div>[2]<a href="https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/deployers/EndpointServiceDeploymentAspect.java" target="_blank">https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/deployers/EndpointServiceDeploymentAspect.java</a><br></div></div><div>[3] <a href="https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSDeploymentActivator.java#L80~L91" target="_blank">https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSDeploymentActivator.java#L80~L91</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 6:32 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Jim,<div><br></div><div>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.</div><div><br></div><div><a href="https://issues.redhat.com/browse/WFLY-13319" target="_blank">https://issues.redhat.com/browse/WFLY-13319</a><br></div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>The first DeploymentUnitProcessor to identify that an Elytron SecurityDomain is to be used will then set the ServiceName of the SecurityDomain to use.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 8:10 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Darran, <div>Did you get time to look at this reproducer? Any findings ?</div><div>Thanks,</div><div>Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 2:00 PM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks Darran. I uploaded the war deployment and reproduce steps readme to <a href="https://github.com/jimma/elytron-null-securitydomain" target="_blank">https://github.com/jimma/elytron-null-securitydomain</a>.<div>Let me know if this helps to debug why the SecurityDomain is not associated. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 12:33 AM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">TBH Jim, I think I would need to dig into the code with a debugger to double check what is happening there.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 1, 2020 at 11:29 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Darran, <div><br></div><div>The SecurityDomain.getCurrent() returns null when there is "other" security domain in jboss-web.xml and no “<span style="color:rgb(0,0,0)">security-constraint” defined in web.xml like:</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">-------------jboss-web.xml---------------------</span></div><div><jboss-web><br> <security-domain>other</security-domain><br></jboss-web></div><div><span style="color:rgb(0,0,0)">--------------web.xml------------------------------</span></div><div><web-app<br> version="2.5" xmlns="<a href="http://java.sun.com/xml/ns/javaee" target="_blank">http://java.sun.com/xml/ns/javaee</a>" <br> xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance" target="_blank">http://www.w3.org/2001/XMLSchema-instance</a>" <br> xsi:schemaLocation="<a href="http://java.sun.com/xml/ns/javaee" target="_blank">http://java.sun.com/xml/ns/javaee</a> <a href="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" target="_blank">http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd</a>"><br> <servlet><br> <servlet-name>TestService</servlet-name><br> <servlet-class>org.jboss.test.ws.jaxws.samples.wsse.policy.jaas.ServiceImpl</servlet-class><br> </servlet><br> <servlet-mapping><br> <servlet-name>TestService</servlet-name><br> <url-pattern>/*</url-pattern><br> </servlet-mapping><br></web-app><span style="color:rgb(0,0,0)"><br></span></div><div><br></div><div>Does this mean Elytron security domain mapped by undertow "other" application domain only is enforced/set for web deployment which contains <<span style="color:rgb(0,0,0)">security-constraint</span>>deployment descriptor ?</div><div>When does SecurityDomain.getCurrent() return null value ?</div><div><br></div><div>Thanks,</div><div>Jim </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 6:35 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 10:33 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Will this work for Undertow default "other" application security domain's reference Elytron SecurityDomain ? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 6:26 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Overall it is the SecurityDomain.getCurrent method you need: -<div><br></div><div><a href="https://wildfly-security.github.io/wildfly-elytron/master-public/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent()" target="_blank">https://wildfly-security.github.io/wildfly-elytron/master-public/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent()</a><br></div><div><br></div><div>If a SecurityDomain is associated with the Thread's context class loader it will be returned.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 10:22 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2020 at 6:07 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div></div></blockquote><div>I'll try it . Can you please point me some code example or test code?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>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.</div></div></blockquote><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 13, 2020 at 8:20 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 8:12 PM Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Is it possible to identify the revelevent DeploymentUnitProcessors in this process along with their phase and priority so we can check the ordering.</div></blockquote><div><br></div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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 :</div><div><a href="https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L114" target="_blank">https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L114</a><br></div><div>Is there better api/approach to perform this kind of method invocation ?</div><div><br></div><div>Thanks,</div><div>Jim</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 11:45 AM Jim Ma <<a href="mailto:ema@redhat.com" target="_blank">ema@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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"<div>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 ?</div><div><br></div><div>[1]<a href="https://issues.redhat.com/browse/WFLY-12765" target="_blank">https://issues.redhat.com/browse/WFLY-12765</a> </div><div>[2] <a href="https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/subsystem/ApplicationSecurityDomainService.java" target="_blank">https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/subsystem/ApplicationSecurityDomainService.java</a></div><div><br></div><div>Cheers,</div><div>Jim</div><div><br></div><div><br></div></div>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>