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

Darran Lofthouse darran.lofthouse at jboss.com
Mon Jul 6 07:55:43 EDT 2020 

On Mon, Jul 6, 2020 at 12:21 PM Jim Ma <ema at redhat.com> wrote:

> Hi Darran,
> This looks good. Please go ahead to submit pull requests.
> 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 ?
>

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.


> Thanks,
> Jim
>
> On Mon, Jul 6, 2020 at 4:01 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> Hello Jim,
>>
>> Just wanted to check how your early reviews of the changes have gone?
>>
>> 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.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On Tue, Jun 9, 2020 at 9:38 AM Jim Ma <ema at redhat.com> wrote:
>>
>>> Hi Darran,
>>> 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.
>>>
>>> Cheers,
>>> Jim
>>>
>>> On Mon, Jun 8, 2020 at 6:45 PM Darran Lofthouse <
>>> darran.lofthouse at jboss.com> wrote:
>>>
>>>> I have two topic branches prepared with the solution I think I can make
>>>> use of for now.
>>>>
>>>> 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.
>>>>
>>>> The two topic branches are:
>>>>
>>>> https://github.com/darranl/wildfly-core/tree/WFCORE-4962
>>>> https://github.com/darranl/wildfly/tree/WFLY-13319
>>>>
>>>> Unless I run into any more testing issues I believe these are now
>>>> complete.
>>>>
>>>> If the Elytron subsystem is installed the following will be attached to
>>>> the DeploymentUnit at Phase.STRUCTURE 0x2300:
>>>>
>>>>
>>>> https://github.com/darranl/wildfly-core/blob/WFCORE-4962/server/src/main/java/org/jboss/as/server/security/SecurityMetaData.java
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Regards,
>>>> Darran Lofthouse.
>>>>
>>>>
>>>>
>>>> On Tue, Jun 2, 2020 at 11:38 AM Darran Lofthouse <
>>>> darran.lofthouse at jboss.com> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 7, 2020 at 9:37 AM Darran Lofthouse <
>>>>> darran.lofthouse at jboss.com> wrote:
>>>>>
>>>>>> 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/20200706/779d6a23/attachment-0001.html

More information about the wildfly-dev mailing list