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

Darran Lofthouse darran.lofthouse at jboss.com
Mon Mar 16 06:26:03 EDT 2020


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/20200316/86ab50bc/attachment.html 


More information about the wildfly-dev mailing list