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

[ELY-2583] Make requestURI and Source-Address available from RealmSuccessfulAuthenticationEvent and RealmFailedAuthenticationEvent #1952

Merged
merged 1 commit into from
Jan 10, 2024

Conversation

Skyllarr
Copy link
Contributor

@Skyllarr Skyllarr commented Sep 11, 2023

Copy link
Contributor

@fjuma fjuma left a 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() {
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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));
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fjuma Added

gaol added a commit to gaol/wildfly-elytron that referenced this pull request Sep 13, 2023
…LY-2583] Make requestURI and Source-Address available from RealmSuccessfulAuthenticationEvent and RealmFailedAuthenticationEvent
@Skyllarr Skyllarr force-pushed the JBEAP-25337 branch 2 times, most recently from ee94a77 to c84d020 Compare October 23, 2023 11:46
@Skyllarr
Copy link
Contributor Author

@fjuma This PR was updated to use a new Callback to avoid using MechanismInformation interface since that is meant to carry information about the mechanism. This also avoids introducing new method to public interface

import java.net.URI;

/**
* A {@link javax.security.auth.callback.Callback} to inform a server authentication context about current authenticaiton request.
Copy link
Contributor

Choose a reason for hiding this comment

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

s/authenticaiton/authentication

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

*/
private final URI requestUri;

public RequestInformationCallback(URI requestUri) {
Copy link
Contributor

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.

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

this.requestUri = requestUri;
}

/**
Copy link
Contributor

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.

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

@@ -110,7 +113,7 @@ public String getMechanismName() {
public String getHostName() {
return hostName;
}
})});
}), new RequestInformationCallback(request.getRequestURI())});
Copy link
Contributor

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.

Copy link
Contributor Author

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!

Copy link
Contributor Author

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

Copy link
Contributor

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.

@@ -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();
Copy link
Contributor

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.

Copy link
Contributor Author

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 {
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 this should be called RequestInformationCallbackServerMechanismFactory to be consistent with other the factories, right?

Copy link
Contributor

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.

Copy link
Contributor Author

@Skyllarr Skyllarr Nov 20, 2023

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;
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be final.

Copy link
Contributor Author

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;
Copy link
Contributor

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.

Copy link
Contributor Author

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();
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fjuma Thank you, updated

@Skyllarr
Copy link
Contributor Author

Hi @darranl , this PR now adds a new RequestInformationCallback and new SetRequestInformationCallbackServerMechanismFactory to pass the request URI to server authentication context . Do you agree with this approach? Thanks!

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.

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.

@Skyllarr Skyllarr force-pushed the JBEAP-25337 branch 2 times, most recently from 4e62872 to 5e79fa5 Compare November 27, 2023 20:33
@Skyllarr
Copy link
Contributor Author

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.

@darranl Thanks for review! Based on your comment I decided to change the callback to have a HashMap<String, Object> properties instead of only URI to make it more generic for the future. Can you please have another look? Thank you!

@Skyllarr Skyllarr force-pushed the JBEAP-25337 branch 2 times, most recently from 1a53535 to 39d356d Compare November 28, 2023 15:28
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());
Copy link
Contributor Author

@Skyllarr Skyllarr Nov 28, 2023

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!

Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fjuma Thanks, it is a good idea, though it might make make an unneeded precedence that the REQUEST_URI should be one of the properties or that all possible properties should be placed there.
@darranl WDYT ?

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 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?

Copy link
Contributor Author

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!

…cessfulAuthenticationEvent and RealmFailedAuthenticationEvent
Copy link
Contributor

@fjuma fjuma left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants