[
https://issues.apache.org/jira/browse/GUACAMOLE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18091450#comment-18091450
]
David Bateman commented on GUACAMOLE-808:
-----------------------------------------
Yeah, sorry I have a terrible habit of thinking out aloud in chats.. Using the
event class doesn't really work in any case..
There are multiple problems that need to be addressed for this to work, and
treating them should allow redirection for all authentication providers. Need
to go back to exactly how the authentication process works and look at what is
missing at each step.. Here is how I see things at this point for a scenario
where an unauthenticated user attemps to connect to "/#/settings/sessions"
# The user connects to "/#/settings/sessions", which loads the static content
including the javascipt "authenticationService.js". The method
authenticationService.authenticate performs a REST POST to "/api/tokens".. So
the requestURI seen in our authenicateUser methods of our authentication
providers is always "/api/tokens" and not the desired redirection path. *We
therefore need to include the desired redirection path as a parameter to
/api/tokens in authenticationService.authenticate*
# The java method TokenRESTService.createToken recieves this post and
authenticates with AuthenticateService.authenticate which enumerates all of the
suplied authentication providers. There are two cases.
** For authentication providers that don't need a redirection like the JDBC
providers, the redirection path should be returned as part of the
authenticatedUser, and it could be recovered from
authenticatedUser.getCredentials().getRequestDetails() if we also store the
requestURI here.
** This won't work for authentication providers needing a redirection, as it
will be ta second call to "/api/tokens" with the patch supplied by
openid-redirect-id for example that will be seen in the requestURI in the
second call to our authenicateUser method. The SSO authenication user method
must therefore as you say store the redirection path in session data, and this
part should indeed be promoted to the base class as they'll all need it
This has several other implications
* *The AutheticatedUser interface class should include a redirection path,
and the derived classes should implement the code to set this value*
* *The SSO base class needs a session manager that stores the redirection path
on the first call to authenticateUser and sets the redirection path in
authenticatedUser on the second call to authenicateUser*
3. When we come back to AuthenticationService.authenticate we need to treat two
cases,
* An existing login where the redirection path is ignored, and
* A new login where the redirection path is accepted
AuthenticateService.authenticate already distinguishes these two cases and so
what I propose is that
* *The GuacamoleSession class also includes a redirection variable*
* *In AuthenticationService.authenticate this variable is only set for the
case of a new login, elsewise it is set to null*
4. When the authentication comes back to TokenRESTService.createToken we
therefore have the redirection path in the GuacamoleSession only for the cases
when we really want to redirect. From here we could do two things
* *Add a redirection field to APIAuthenticationResult and it if is set, in the
javascript method authenticateService.authenticate, if the redirection is set,
set window.location.href with its value*
* *Seen a javax Response.seeOther(redirection) from
TokenRESTService.createToken and treat it in the javascript
authenticationService.authenticate*
The first is conceptually easier I think.
[~vnick] are you ok with my analysis ? Can you think of other ways to do this ?
In the end this seems quite an intrusive change so not for staging/1.6.1 I
think.
> Support redirecting to originally requested URL after successful SSO login
> --------------------------------------------------------------------------
>
> Key: GUACAMOLE-808
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-808
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-auth-sso-cas,
> guacamole-auth-sso-openid, guacamole-auth-sso-saml
> Reporter: Parth Mishra
> Priority: Minor
>
> Upon successful authentication via OIDC, the user is returned to the redirect
> URI (e.g. {{https://myserver.com/guacamole/}}) even if they were requesting
> another Guacamole resource such as a Connection link. It would be nice if the
> user could be routed to the requested resource after successful
> authentication.
> This way, if they were to click a direct link to a guacamole Connection they
> have access too, the successful authentication via the IDP can reroute them
> directly to the requested connection URL rather than the guacamole UI.
> Typically this is done with encoding the request URL with the "state"
> parameter of OIDC and verifying with the nonce.
> This feature could be really useful for relying on custom frontends without
> having to modify or reimplement the web app.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
