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

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 >>>>>>>>>>>> >>>>>>>>>>>>