[wildfly-dev] Read Elytron security domain from Undertow's ApplicationSecurityDomainService
Darran Lofthouse
darran.lofthouse at jboss.com
Thu Jul 23 10:21:55 EDT 2020
FYI I have had to add a bit more clean up
to EJBDefaultSecurityDomainProcessor - I need a couple more test runs but
hopefully I have it now so will be pushing an update to the branches
either today or tomorrow.
On Wed, Jul 22, 2020 at 12:18 PM Jim Ma <ema at redhat.com> wrote:
> Thanks for the update, Darran. I'll check it hopefully this Friday.
>
> Regards,
> Jim
>
>
> On Wed, Jul 22, 2020 at 6:29 PM Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> 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/20200723/b400d0a9/attachment-0001.html
More information about the wildfly-dev
mailing list