-
Notifications
You must be signed in to change notification settings - Fork 77
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
[ELY-201] Add client side HTTP authentication mechanism support #528
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @keshav-redhat ! I added some minor comments
=== Testing By | ||
// Put an x in the relevant field to indicate if testing will be done by Engineering or QE. | ||
// Discuss with QE during the Kickoff state to decide this | ||
* [ ] Engineering |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be tested by engineering AFAIK
|
||
* [ ] QE | ||
|
||
=== Affected Projects or Components |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
affected projects or components are wildfly-elytron and wildfly
|
||
=== Hard Requirements | ||
|
||
Having a client which can read the elytron configurations and add authorization header with BASIC,BEARER or DIGEST based on challenge it received. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please add using an SSLContext from the elytron configuration tot his list
Having a client which can read the elytron configurations and add authorization header with BASIC,BEARER or DIGEST based on challenge it received. | ||
|
||
=== Nice-to-Have Requirements | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can put http-selector in the nice to have requirements section
=== Non-Requirements | ||
|
||
== Backwards Compatibility | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can write here that it does not affect backwards compatibility because we did not provide any HTTP client before
Now after sending the request we will get a response which is of type HttpResponse.we will determine using the status if the authentication success or failed.If status code is 200 then we will know that authentication is successful. | ||
|
||
If the authentication failure then headers will contain : | ||
www-authenticate=[Basic realm="RealmUsersRoles"] for basic authentication.similar for the other authentication mechanism type like digest,bearer,etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not clear what happens after we receive authentication failure. If the authentication results in failure then we create another request created from the needed information and send this new request to the same URI.
Also what is failure in this context? If we receive response code 500 then it does not make sense to try to add credentials? Can you write here whether by authentication failure do you mean codes 401 or 403 or other?
The actual communication flow and connect method have be tested with arquillian in wildfly where we will call the connect method with required parameter and test it. | ||
|
||
== Community Documentation | ||
//// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Community documentation has to be added to the wildfly repository under docs
older
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Skyllarr ,I did not get this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@keshav-redhat new features are being documented in the upstream wildfly documentation that is located in the docs folder
//// | ||
== Release Note Content | ||
//// | ||
Draft verbiage for up to a few sentences on the feature for inclusion in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Try to draft here a release note content. That should include a brief description of this feature
elytron/ELY-201-Add-client-side-HTTP-authentication-mechanism-support.adoc
Show resolved
Hide resolved
== Test Plan | ||
|
||
To test the above functionality we can add the tests as follows : | ||
Inside tests/base/src/test/java/org/wildfly/security/http/client/ we will create a test class named as ElytronHttpClientTest where we will get an instance of HttpRequest from ElytronHttpClient#evaluateMechanism() method of different authentication mechanism and then we will create an object of TestingHttpServerRequest using request header which we will pass to the evaluateRequest() method of BasicAuthenticationMechanism which is used to evaluate our header values of request method. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am having difficulties understanding this long sentence. Can you please reformulate this? Also by object of TestingHttpServerRequest you mean instance
of right? since the class already exists. Also it is not clear when you are refering to the authentication mechanism of the client and when you are refering to the authentication mechanism of the server
elytron/ELY-201-Add-client-side-HTTP-authentication-mechanism-support.adoc
Show resolved
Hide resolved
elytron/ELY-201-Add-client-side-HTTP-authentication-mechanism-support.adoc
Show resolved
Hide resolved
|
||
== Overview | ||
|
||
Wildfly Elytron already provide client and server side SASL mechanism for server side HTTP authentication mechanism.This will include a client side framework for HTTP authentication mechanisms and implement a set of client side HTTP authentication mechanisms. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some thought of using https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/Authenticator.html?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamezp we did not discuss the Authenticator usage. But it seems that for our use case where we need to obtain not just a password from the elytron configuration but also the ssl context, credentials stored in the credential store, and bearer tokens it is not so clear how the Authenticator would fit in. Let us know if you have any idea or a suggestion for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... ...yeah I see what you mean. It's a bummer there isn't a better API for https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.Builder.html#authenticator(java.net.Authenticator).
@keshav-redhat Just a minor, if you'll have time, you can consider and add to this proposal the ideas you had about how to make this extensible for other clients than java HTTP client, like apache HTTP client for example. Thank you! |
https://issues.redhat.com/browse/ELY-201