[wildfly-dev] Read Elytron security domain from Undertow's ApplicationSecurityDomainService
Jim Ma
ema at redhat.com
Wed Jul 22 07:18:09 EDT 2020
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/20200722/b2b6b3c7/attachment-0001.html
More information about the wildfly-dev
mailing list