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

[Jim Ma]

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/20200401/7eb77548/attachment.html