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

Darran Lofthouse darran.lofthouse at jboss.com
Wed Jul 22 06:28:48 EDT 2020 

I have submitted the PRs as they are for now:
  https://github.com/wildfly/wildfly-core/pull/4276
  https://github.com/wildfly/wildfly/pull/13419

But these changes are still more the beginning than the end, as I say
previously I want to get to the point the DUPs collaboratively define a
security policy before we enter Phase.INSTALL so during Phase.INSTALL all
DUPs can install their services based on the defined policy.

Two areas I am likely to follow up on are:

   1. Making the application-security-domain resources optional where
   legacy security is not installed.
   2. Further deployments such as EE security that can make use of a DUP
   defined security domain instead of requiring managed configuration.

Regards,
Darran Lofthouse.


On Mon, Jul 6, 2020 at 2:21 PM Darran Lofthouse <darran.lofthouse at jboss.com>
wrote:

> At the moment this is the earliest I can get resolution to happen, ideally
> at some point I want to pull it all the way back to somewhere around
> Phase.REGISTER or Phase.FIRST_MODULE_USE at the latest.
>
> The final problem that I ran into was the way web services dynamically a
> complete list of DeploymentUnitProcessors in a sequential block - there is
> no way to interleave any other DeploymentUnitProcessors.  For my resolution
> to work correctly I need to be able to identify that the deployment is a
> web application and we can't identify if it is a web application until
> after the WS deployment processors have marked it as a web application.
>
> But overall the general issue seems to be that over time deployment unit
> processors have been incrementally enhanced over the years with more and
> more happening in Phase.INSTALL which is making coordination much much
> harder
>
> As a starting point I think the deployment unit processors up to and
> including Phase.PARSE are focussed on extracting relevant meta data from
> the deployment they are handling.  Before Phase.INSTALL starts all
> decisions about how the deployment is defined should have already been made
> allowing DeploymentUnitProcessors to get on with installing the services
> for the deployment without too much additional decision making.  If on
> entering Phase.INSTALL all decisions have been made then ordering could be
> largely irrelevant at that stage as the resulting MSC service dependencies
> will define the final order of initialisation.  Between Phase.PARSE and
> Phase.INSTALL there are then five phases that could be used for the
> coordination decisions.
>
> Regards,
> Darran Lofthouse.
>
>
> On Mon, Jul 6, 2020 at 1:14 PM Jim Ma <ema at redhat.com> wrote:
>
>>  If I understand correctly, we can only get the actual/resolved domain
>> security service name from SecurityMetaData after it's resolved.
>> EndpointServiceDeploymentAspect does the inject service etc and is running
>> after Phase.INSTALL 0x1CFF where domain security name is resolved.  Do you
>> think we can resolve security domain name before
>> INSTALL_WS_DEPLOYMENT_ASPECTS, like 0x1c09 ?
>>
>>
>> *    public static final int INSTALL_CDI_VALIDATOR_FACTORY
>> = 0x1C02;    public static final int INSTALL_WS_UNIVERSAL_META_DATA_MODEL
>>      = 0x1C10;    public static final int INSTALL_WS_DEPLOYMENT_ASPECTS
>>           = 0x1C11;*
>>
>> On Mon, Jul 6, 2020 at 7:56 PM Darran Lofthouse <
>> darran.lofthouse at jboss.com> wrote:
>>
>>> 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/20200722/7a7ab3b6/attachment-0001.html

More information about the wildfly-dev mailing list