-
Notifications
You must be signed in to change notification settings - Fork 280
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-2583] Make requestURI and Source-Address available from RealmSuccessfulAuthenticationEvent and RealmFailedAuthenticationEvent #1952
Conversation
2ec6427
to
6c8e29d
Compare
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.
Thanks @Skyllarr! I've added some feedback.
@@ -53,6 +53,10 @@ public interface MechanismInformation { | |||
*/ | |||
String getProtocol(); | |||
|
|||
default String getRequestURI() { |
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.
MechanismInformation
already provides getHost
and getProtocol
methods. Just wondering if we can make use of these existing methods instead of introducing a new getRequestURI
method. (We'd need to check if the information provided by the host and protocol would be sufficient for the reporter.)
Note that MechanismInformation
is public API.
So if we decide that a new method is needed, we should check with @OndrejKotek to see if adding a new method here would be ok for 1.15.x.
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.
@fjuma We can make use of the existing getHost
and getProtocol
methods instead. The URI information would not have a full requested path that way, just the host and protocol.
However if we want to avoid adding a new method to the public API we might not have a better choice. So if @OndrejKotek thinks we should not introduce a new API method to the maintenance branch, we can check with the reporter about providing only the host+port information
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 is not up to me to decide. Open a discussion on https://issues.redhat.com/browse/JBEAP-25337 please as it's up to the QE CP (Peter Mackay, Dan Cihak) and SET team to ack such changes.
@Override | ||
public void handleRealmEvent(RealmEvent event) { | ||
if (event instanceof RealmSuccessfulAuthenticationEvent) { | ||
assertEquals("10.12.14.16", ((RealmSuccessfulAuthenticationEvent) event).getAuthorizationIdentity().getRuntimeAttributes().get("Source-Address").get(0)); |
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.
As a sanity check, would also be good to verify that it's possible to retrieve the principal in both the successful and failed cases.
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.
@fjuma Added
…LY-2583] Make requestURI and Source-Address available from RealmSuccessfulAuthenticationEvent and RealmFailedAuthenticationEvent
6c8e29d
to
785cbb3
Compare
ee94a77
to
c84d020
Compare
@fjuma This PR was updated to use a new Callback to avoid using |
import java.net.URI; | ||
|
||
/** | ||
* A {@link javax.security.auth.callback.Callback} to inform a server authentication context about current authenticaiton request. |
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.
s/authenticaiton/authentication
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.
Fixed
*/ | ||
private final URI requestUri; | ||
|
||
public RequestInformationCallback(URI requestUri) { |
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.
Should add Javadoc for this.
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.
Fixed
this.requestUri = requestUri; | ||
} | ||
|
||
/** |
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.
Just minor but since this is public API, we should also add a description for the 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.
Fixed
@@ -110,7 +113,7 @@ public String getMechanismName() { | |||
public String getHostName() { | |||
return hostName; | |||
} | |||
})}); | |||
}), new RequestInformationCallback(request.getRequestURI())}); |
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.
Should we be handling the new RequestInformationCallback
from this class? Wondering if it would make more sense to introduce a new SetRequestionInformationMechanismFactory
. WildFly Core would need to be updated accordingly.
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.
@fjuma I was not sure at first since the HttpServerAuthenticationMechanismFactory
is documented as Factory to create authentication mechanisms
which did not seem related to logging or similar purpose, but it's true that this requestURI
is a bit similar to already existing SocketAddressCallbackServerMechanismFactory
and its socket address handling. So I made the changes, let me know what you think? Thank you!
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.
@fjuma Here is affiliated commit for wildfly-core Skyllarr/wildfly-core@f9cf847 , if you like the changes I can create a WFCORE issue and submit this as a PR
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.
The Core changes look good to me.
c84d020
to
d21994a
Compare
@@ -73,6 +74,7 @@ public String getMechanismName() { | |||
public void evaluateRequest(HttpServerRequest request) throws HttpAuthenticationException { | |||
String host = request.getFirstRequestHeaderValue(HOST); | |||
String resolvedHostName = null; | |||
URI requestedUri = request.getRequestURI(); |
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 this needed here? It doesn't look like it's used.
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.
Removed
* | ||
* @author <a href="mailto:[email protected]">Diana Krepinska</a> | ||
*/ | ||
public class SetRequestInformationMechanismFactory implements HttpServerAuthenticationMechanismFactory { |
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 think this should be called RequestInformationCallbackServerMechanismFactory
to be consistent with other the factories, right?
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 see now, we also have a SetMechanismInformationMechanismFactory
so that's probably why you named this SetRequestInformationMechanismFactory
. That's fine then.
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.
@fjuma I renamed this because I was thinking the same before. The SocketAddressCallbackServerMechanismFactory
also uses the Callback in its name. I think the RequestInformationCallbackServerMechanismFactory
is more clear?
*/ | ||
public class SetRequestInformationMechanismFactory implements HttpServerAuthenticationMechanismFactory { | ||
|
||
private HttpServerAuthenticationMechanismFactory delegate; |
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 can be final.
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.
Done
* @param delegate the wrapped mechanism factory | ||
*/ | ||
public SetRequestInformationMechanismFactory(final HttpServerAuthenticationMechanismFactory delegate) { | ||
this.delegate = delegate; |
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.
There should be a check here to make sure the delegate isn't null.
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.
Done
try { | ||
callbackHandler.handle(new Callback[]{new RequestInformationCallback(request.getRequestURI())}); | ||
} catch (Throwable e) { | ||
throw log.unableToLocateMechanismConfiguration(e).toHttpAuthenticationException(); |
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.
Should this be updated to request configuration?
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.
@fjuma What do you mean by request configuration? I think now that I should update this to:
catch (IOException | UnsupportedCallbackException e) {
throw new HttpAuthenticationException(e);
}
wdyt?
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.
"unableToLocateMechanismConfiguration" seems specific to the "SetMechanismInformationMechanismFactory"
Your suggested update looks fine.
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.
@fjuma Thank you, updated
Hi @darranl , this PR now adds a new |
d21994a
to
9f0768b
Compare
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.
Looks good for me.
Looking at this could be tempted to even go one step further and have a CallBack that allows a mechanism to generically send over attributes it feels appropriate but that should probably have further discussion.
4e62872
to
5e79fa5
Compare
@darranl Thanks for review! Based on your comment I decided to change the callback to have a |
1a53535
to
39d356d
Compare
HashMap<String, Object> props = ((RequestInformationCallback) callback).getProperties(); | ||
Attributes runtimeAttributes = new MapAttributes(); | ||
for (Map.Entry<String, Object> entry : props.entrySet()) { | ||
runtimeAttributes.addFirst(entry.getKey(), entry.getValue().toString()); |
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.
@darranl @fjuma Updated this PR to use a map of <String, Function> as properties
in the RequestInformationMechanismFactory. I am not sure if it is okay to add all of the properties to the runtimeAttributes and not just Request-URI
? I wanted to introduce a public static final String REQUEST_URI
somewhere in this repo, but I did not find a good place without introducing new dependencies or classes with constants, and this is a maintenance branch also. But maybe putting all of the properties from the callback into the runtimeAttributes
indiscriminately makes sense now.
"Request-URI" constant is defined in the wildfly-core repo PR.
Also, this is relying on the toString()
method being implemented well on the entry.getValue()
.
Let me know what you think. Thanks!
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.
Since this is more generic now, adding all of the properties to the runtimeAttributes
makes sense to me.
For the REQUEST_URI
constant, maybe that could be added to the SetRequestInformationCallbackMechanismFactory
and then it could be used from WildFly Core?
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.
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 think I would be tempted to try and keep the list of properties out of Elytron for now but in WildFly Core it should define Functions for all properties.
Late on I think custom implementations of the functions could be added to extract Cookie information etc so may be good to control the default behaviour over there?
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.
@darranl Okay sounds good to me, and that is the current state of these PRs. Request-URI and its function is currently defined in wildfly-core as seen in the PR and if any other functions will be added in the future, those can be added to the same place in wildfly-core. Please check that your approval on wildfly-core still holds as the code has been changed since your last approval. Thank you!
@fjuma Let us know if you agree and if so, can you please approve this PR and the wildfly-core PR? Thank you!
39d356d
to
8337be0
Compare
…cessfulAuthenticationEvent and RealmFailedAuthenticationEvent
8337be0
to
8bf64cd
Compare
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.
Thanks, @Skyllarr! Looks good.
https://issues.redhat.com/browse/ELY-2583