mooli tayer has posted comments on this change.
Change subject: core: Introduce new authentication interfaces
......................................................................
Patch Set 8:
(6 comments)
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/authentication/AuthenticatedRequestWrapper.java
Line 4: import javax.servlet.http.HttpServletRequest;
Line 5: import javax.servlet.http.HttpServletRequestWrapper;
Line 6:
Line 7: /**
Line 8: * This class wraps a HTTP request when the authentication process has
suceeded in order to replace the principal used
a HTTP -> an HTTP
suceeded -> succeeded
Line 9: * by default by the container with one containing the name of the user
that has been authenticated by the our own
Line 10: * authentication mechanism.
Line 11: */
Line 12: public class AuthenticatedRequestWrapper extends
HttpServletRequestWrapper {
....................................................
File
backend/manager/modules/common/src/main/java/org/ovirt/engine/core/authentication/AuthenticationFilter.java
Line 14: import javax.servlet.http.HttpServletResponse;
Line 15: import javax.servlet.http.HttpSession;
Line 16:
Line 17: /**
Line 18: * This filter should be added to the {@code web.xml} file to the
applications that wan't to use the authentication
wan't -> want.
Line 19: * mechanism implemented in this package.
Line 20: */
Line 21: public class AuthenticationFilter implements Filter {
Line 22: // The authentication profiles used to perform the authentication
process:
Line 25: // We store a boolean flag in the HTTP session that indicates if
the user has been already authenticated, this is
Line 26: // the key for that flag:
Line 27: private static final String AUTHENTICATED_ATTR =
AuthenticationFilter.class.getName() + ".authenticated";
Line 28:
Line 29: // When an user has been authenticated we store its login name in
the HTTP session, this is the key for that name:
When an user -> When a user
Line 30: private static final String NAME_ATTR =
AuthenticationFilter.class.getName() + ".name";
Line 31:
Line 32: // In order to support several alternative authenticators we store
their names in a stack inside the HTTP session,
Line 33: // this is the key for that stack:
Line 70: // authentication to perform:
Line 71: findNegotiatingProfiles();
Line 72: if (profiles.isEmpty()) {
Line 73: chain.doFilter(req, rsp);
Line 74: return;
I would think In this case we should act like in line 139
(invalidate session & set status(SC_UNAUTHORIZED))
?
Then we can say user is authenticated <=> there exists an authentication
profile that authenticated it
?
Line 75: }
Line 76:
Line 77: // Perform the authentication:
Line 78: doFilter((HttpServletRequest) req, (HttpServletResponse) rsp,
chain);
Line 111:
Line 112: // If the negotiation isn't finished then we assume that
the response has been populated by the
Line 113: // authenticator and we just let the container sent it
back to the client:
Line 114: if (result == null) {
Line 115: return;
1.) Does this not interfere proceeding with the filter chain (i.e filters
unrelated to authentication)?
chain.doFilter(req, rsp);
2.) I understand if result is null authentication isn't completed and also we
do not want to continue with other authentication profiles yet. so two
questions:
a.) How will it look from the user point of view? will he need a refresh?
b.) when we call that authentication profile next time with the same request
how will it know to continue the same operation?
Line 116: }
Line 117:
Line 118: // If the negotiation is finished and authentication
succeeded then we have to remember in the session that
Line 119: // the user has been authenticated and its login name,
also we need to clean the stack of authenticators and
Line 137: // If we are here then there are no more authenticators to
try so we need to invalidate the session and reject
Line 138: // the request:
Line 139: session.invalidate();
Line 140: rsp.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
Line 141: }
This filter isn't being used yet (web.xml)?
It is in a later patch?
--
To view, visit http://gerrit.ovirt.org/15596
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If84a0c9d6553d81cdbbe224972696f169cca90d4
Gerrit-PatchSet: 8
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Alexander Wels <[email protected]>
Gerrit-Reviewer: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Martin Peřina <[email protected]>
Gerrit-Reviewer: Oved Ourfali <[email protected]>
Gerrit-Reviewer: Ravi Nori <[email protected]>
Gerrit-Reviewer: Yair Zaslavsky <[email protected]>
Gerrit-Reviewer: mooli tayer <[email protected]>
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: Yes
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
