Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WFLY-12190] EJB: EJB over HTTP discovery configuration #12887

Merged
merged 5 commits into from Sep 17, 2020

Conversation

tadamski
Copy link
Contributor

@tadamski tadamski commented Jan 8, 2020

https://issues.redhat.com/browse/EAP7-1236
https://issues.redhat.com/browse/WFLY-12190

Depends on:
#13305

Thanks for submitting your Pull Request!

Please make sure your PR meets the following requirements:

  • Pull Request title is properly formatted: [WFLY-XYZ] Subject or WFLY-XYZ Subject
  • Pull Request contains link to the JIRA issue(s)
  • Pull Request contains description of the issue(s)
  • Pull Request does not include fixes for issues other than the main ticket
  • Attached commits represent units of work and are properly formatted

For bigger changes, major and minor component upgrades make sure your PR also meets following requirements:

  • Pull Request requires a change to the documentation
  • Documentation have been updated accordingly
  • Tests were added to cover changes

For new features ensure as well:

  • Analysis was done
  • Test Plan has been done
  • Tests were verified in advance

If you are not an active contributor of the WildFly project you can request sponsorship by one of the members to help guide you through the process.

@darranl darranl added Feature PR provides a new feature missing-reqs Features missing one or more of the pre-merge requirements labels Jan 8, 2020
Copy link
Contributor

@darranl darranl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The model description constants need defining.

However as on the analysis before we add a new server to server protocol we need to review the security implications.

@tadamski
Copy link
Contributor Author

@darranl I have updated the description. I have also added the possibility of HTTP discovery from standalone client (in attached PRs). Regarding security, EJB over HTTP protocol is integrated with Elytron and the invocations are secured. Specifically, I had to provide Elytron configuration for the tests to pass (discovery invocations to succeed). I agree that it has to be double-checked though.

@darranl
Copy link
Contributor

darranl commented Jan 14, 2020

@tadamski I know the server side is already covered by Elytron security, the bit I am not sure about is the client side of these server to server connection. In this case there are a few scenarios that may need some integration: -

  • SSLContext
  • Authentication Configuration
  • Identity Propagation using Delegated Credential

@tadamski
Copy link
Contributor Author

@darranl OK, I will try to investigate those but I would probably need some help. OTOH server->server invocations are already working in WildFly (with static discovery) so we may need to double-check that those are fine as well.

@bstansberry
Copy link
Contributor

@tadamski #12891 no longers includes the http-client part of this; it's just a bug fix update. The http-client part of this is now in a 1.1 release so this PR should include the upgrade to that.

Copy link
Contributor

@pferraro pferraro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change requires a model version bump, as well as transformers and transformation tests.

@darranl
Copy link
Contributor

darranl commented Apr 30, 2020

@tadamski we haven't really followed up on this together, it looks like it has a merge conflict anyway but do we want to set something up so we can look at the security implications in more detail?

@tadamski
Copy link
Contributor Author

@darranl I have to update this PR but this is mostly config stuff. The key PR is wildfly/wildfly-http-client#29 on which this PR relies. I would be happy to discuss it.

@luck3y
Copy link
Contributor

luck3y commented May 4, 2020

test, please ignore

@tadamski tadamski force-pushed the WFLY-12190 branch 2 times, most recently from a45fab7 to a79e3f9 Compare May 7, 2020 09:58
@jamezp jamezp added rebase-this PR has a merge conflict. and removed missing-reqs Features missing one or more of the pre-merge requirements labels May 19, 2020
@jamezp
Copy link
Member

jamezp commented May 19, 2020

I've removed the missing-reqs label as there was an agreement the test development can be late on this feature.

@fl4via
Copy link
Contributor

fl4via commented May 19, 2020

This PR depends on #13305

@wildfly-ci wildfly-ci added the deps-ok Dependencies have been checked, and there are no significant changes label Jul 11, 2020
@tadamski tadamski force-pushed the WFLY-12190 branch 2 times, most recently from d57f27d to dfeb23f Compare July 12, 2020 20:37
@tadamski
Copy link
Contributor Author

@jamezp merged; failing test seem unrelated; this should be ready to merge

@zhantemirov
Copy link

I see all checks passing, do anything else prevent this PR from merging? Thanks

Copy link
Contributor

@bstansberry bstansberry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made some comments.

For this one to move forward we should get an approval from @darranl.

==== <remote-http-connection>

`remote-http-connection` tag is used to define dynamic discovery based on
HTTP procol:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/procol/protocol

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the main question I would like to ask is - is there sufficient test coverage of clients using authentication client configuration for a dynamically discovered destination?

As mentioned earlier we have aspects such as SSL and the credentials for authentication which should already be covered by the EJB client to verification that the behaviour is correct. In this case I believe it will be preferable for the resolved configuration to be based on the discovered destination.

Copy link
Contributor Author

@tadamski tadamski Sep 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test coverage for the dynamically discovered destinations would require additional analysis. OTOH, dynamic discovery is main route of invocation also for remoting and this commit just adds this feature for HTTP. Currently EAP/WildFly already relies on dynamic invocation and if we decide that the testsuite have to be extended it should be done for a number of scenarios, possibly independently of this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, lets go with what we have here - if you are happy HTTP is just using the same pattern as the existing approaches we should be good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, but just to clarify cause I'm not sure if I understand correctly. Discovery provider and HttpEjbReceiver (which is used to perform invocation to discovered destination) (also other receivers) resolve their AuthenticationContexts independently:
https://github.com/wildfly/wildfly-http-client/blob/master/ejb/src/main/java/org/wildfly/httpclient/ejb/HttpEJBReceiver.java#L132

Should this be modified?

@tadamski tadamski force-pushed the WFLY-12190 branch 3 times, most recently from d9af418 to a758a31 Compare September 9, 2020 09:21
@bstansberry
Copy link
Contributor

/retest

@bstansberry
Copy link
Contributor

The issues I've raised have all been addressed, but the discussion with Darran remains open.

@@ -0,0 +1,85 @@
package org.jboss.as.test.multinode.ejb.http;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing header

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@darranl
Copy link
Contributor

darranl commented Sep 10, 2020

I have one comment for testing that I don't think should hold up this PR so is something more general. At the moment our testsuite is becoming very slow to execute so the pattern of Configure -> Deploy -> Single Test -> Undeploy -> Revert Configuration adds a lot of steps for one test. Ideally if we can find ways a common deployment can be used for multiple scenarios we can execute multiple tests for a single pair or configure and pair of deploy tasks. Ideally finding ways to test the success and failure scenarios under the same test case.

But in the case of this specific change I see we have some simple authentication client configuration where a single configuration is available but I would still like to see something where we test a configuration where the correct configuration is only resolved / resolvable after discovery. I don't necessarily have an issue with that being in a follow up PR if we can make sure it happens.

The reason I am seeing this piece as important is because it will be an area of code we must maintain for backwards compatibility so once we release a Final version we will not be able to change the resolution logic without the risk of breaking something developed against the original behaviour.

Copy link
Contributor

@bstansberry bstansberry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tadamski This needs an update to the transformers to the previous management API version:

https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJBTransformers.java#L289

Ejb3SubsystemUnitTestCase and Ejb3TransformersTestCase should cover it as well.

@bstansberry
Copy link
Contributor

@tadamski https://issues.redhat.com/browse/WFLY-13878 is to track my last request.

@chengfang
Copy link
Contributor

@bstansberry I'll update the transformer to handle the new element remote-http-connection

@bstansberry bstansberry mentioned this pull request Sep 17, 2020
@bstansberry bstansberry merged commit 850852d into wildfly:master Sep 17, 2020
@tadamski tadamski deleted the WFLY-12190 branch July 6, 2022 12:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deps-ok Dependencies have been checked, and there are no significant changes Feature PR provides a new feature
Projects
None yet
10 participants