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

Darran Lofthouse darran.lofthouse at jboss.com
Thu May 7 04:37:56 EDT 2020 

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 at redhat.com> 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-integration/src/main/java/org/jboss/as/webservices/service/EndpointService.java
> [2]
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/deployers/EndpointServiceDeploymentAspect.java
> [3]
> https://github.com/wildfly/wildfly/blob/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/dmr/WSDeploymentActivator.java#L80~L91
>
> On Wed, May 6, 2020 at 6:32 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> 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 at redhat.com> 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 at redhat.com> 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 at jboss.com> 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 at redhat.com> 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 at jboss.com> 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 at redhat.com> 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 at jboss.com> wrote:
>>>>>>>>
>>>>>>>>> Overall it is the SecurityDomain.getCurrent method you need: -
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://wildfly-security.github.io/wildfly-elytron/master-public/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent()
>>>>>>>>>
>>>>>>>>> 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 at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Mar 16, 2020 at 6:07 PM Darran Lofthouse <
>>>>>>>>>> darran.lofthouse at jboss.com> 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 at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 12, 2020 at 8:12 PM Darran Lofthouse <
>>>>>>>>>>>> darran.lofthouse at jboss.com> 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-integration/src/main/java/org/jboss/as/webservices/invocation/AbstractInvocationHandler.java#L114
>>>>>>>>>>>> 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 at redhat.com>
>>>>>>>>>>>>> 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/jboss/as/ejb3/subsystem/ApplicationSecurityDomainService.java
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200507/6615ccfb/attachment-0001.html

More information about the wildfly-dev mailing list