Generic OAuth2 redirects to homepage instead of logging in

djelectro

Hello,

I am using the new Oauth plugin as part of 1.17 with a "generic" OAuth provider. My issue is that once the Oauth flow completes (select provider in helpdesk -> oauth provider flow -> back to helpdesk), I am redirected back to the osticket homepage (even if I try to log in as an agent) and I am not logged in. No log messages are generated nor errors appear (even with log mode set to debug). Apache logs show a 302 redirect on the /api/auth/oauth route. Mod_rewrite is enabled. I'm not really sure where to go/troubleshoot from here since there are absolutely no logs about the route at all.

KevinTheJedi

djelectro

Check to make sure the attributes are correct. If there is a mismatch this can happen.

Also, you can wait for RC4 and a new test build of the plugin to see if we’ve already addressed some underlying issue. Should be releasing those this week or next.

Cheers.

Bmill

Hey team,

I have the same issue. Looks like auth works but when it returns with rewrite enabled, we are returned to the landing page.

I guess my question is: what should the rewrite land to in a default installation?

We are using Ost1.17rc3, windows server 2019, iis 10. URL rewrite 2.1.

Thoughts?

che75

Hi all,

I have tested this morning the 1.17 rc3, same behavior:

User is redirected to the SSO platform
Authentification
Redirected to Ost
Redirected to landing page, and the user seems not to be connected

I've checked the attributes: everything seems good and well populated into the ost database.
When a delete the user from ost, and use the OAuth flow, it will be created again successfully.

In the system log, in debug mode, I see the "User login" event, but on the frontend part, the user seems not to be connected. Same behavior with Agent part, we are redirected to the landing page.

Your architecture:

ost 1.17rc3
Ubuntu 22.04
Apache2
MySQL 5.6
URL Rewrite activated
Keycloak as OAuth2 provider

I will wait for RC4 to check again 🙂

KevinTheJedi

che75

I am unable to replicate your issue. Whenever I was being redirected to the homepage after signing in it was due to incorrect attribute names and potentially a wrong URL somewhere.

Cheers.

che75

Thanks @KevinTheJedi for your reply and your advice.

I've checked the 4 user attributes mapping :

User identifier (well saved in the new user's field : "Username")
Given name / Surname (saved in "Name")
Email address (saved in "email" field)

When I modify one of those fields on Keycloak, they are well saved in osticket, so I assume the mapping is correct.

For URLs, I checked again, everything is ok.

Callback Endpoint: http://oursupporturl.com/api/auth/oauth2
Authorization Endpoint: https://oursso.com/auth/realms/our_realm/protocol/openid-connect/auth
Token Endpoint: https://oursso.com/auth/realms/our_realm/protocol/openid-connect/token
Resource Details Endpoint: https://oursso.com/auth/realms/our_realm/protocol/openid-connect/userinfo

On Keycloak, I have authorized the redirect on the URL http://oursupporturl.com/api/auth/oauth2.

During the worflow, everything seems to be coherent:

When I click on the button "SSO connect" inside the ost connection page: http://oursupporturl.com/login.php?do=ext&bk=oauth2.user.p1i1
I'm redirected to: https://oursupporturl.com/auth/realms/our_realm/protocol/openid-connect/auth?state=c14a1e5bd93412dc7357e2616385f1f1&scope=email%20profile%20offline_access%20roles&response_type=code&approval_prompt=auto&redirect_uri=http%3A%2F%2Foursupporturl.com%2Fapi%2Fauth%2Foauth2&client_id=osticket
After logging completion, I'm redirect to: http://oursupporturl.com/api/auth/oauth2?state=62ca41b9c0eb35ae6d0ca11c413d3063&session_state=fa0113e2-15e5-4945-83f9-a951c327cf85&code=3a3bd379-596e-44a8-97dd-aa4f3dcfcea7.fa0113e2-15e5-4945-83f9-a951c327cf85.149949cf-9c78-4248-972e-9240ec212b22
At this moment, I saw the "User login" event with my email address inside system logs in Debug mode (seems to be OK)
End finally, I'm redirected to "http://oursupport.com" landing page, not connected (with "Guest user - Sign In" in the header)

Can I activate somewhere more debug logs to try to understand? I have no error in System logs tab (in DEBUG mode).

KevinTheJedi

che75

Go to include/class.auth.php and search for regenerateSession(. There should be 2 lines with this method and you want to comment these lines out, save the changes, and fully retest login.

We should have a fix coming for this in RC4.

Cheers.

prayogi

KevinTheJedi Hi Kevin, would you like inform which lines should be commented out, i search for regenerateSession( but cant find it

Bmill

Hey Kevin, thanks for being on top of it and so supportive.

We are still experiencing all the same described symptoms. We did go in and comment those lines on Line637 and Line854. Its still the same results.

We are attempting a fresh install of RC3, verse using the upgrade path. We'll let you know if we have any different success.

Update: So we did a fresh install of OSTicket RC3 with a new db, and came to the same results. After authing with the IdP, the token is returned to OSTicket, but goes to the landing page with no user/agent logged in.

KevinTheJedi

Bmill

Then you definitely don’t have something configured correctly or you didn’t download the latest build of the plugin.

Cheers.

che75

@KevinTheJedi

Works perfectly for me! I've commented the two lines out and I'm connected now.
I don't known if it's already in the pipe, but It should be awesome to be able to disable the change password feature in the user profile when it's connected using OAuth.

Next release looks very promising indeed. Thanks for your time @KevinTheJedi!

KevinTheJedi

che75

Do you have the password policy plugin installed/enabled? If so this is a bug that we are working on.

Cheers.

che75

@KevinTheJedi

No, I have only the OAuth2 Client enabled, and the Help Desk Audit installed but not activated

Since I'd deactivated the two lines in include/class.auth.php, everything works perfectly. I don't have found any other bug on the RC.

KevinTheJedi

che75

Ah, I see now. You were saying to disable the option for Change Password for Users if they are using OAuth2. Well, even if you have OAuth2 installed/configured/enabled you still have local authentication (As what happens when OAuth2 fails for whatever reason? They won't be able to access the system at all). With this the standard rules still apply like being able to change/reset the local password. So with this in mind I doubt this will ever come to fruition.

Cheers.

ntozier

@KevinTheJedi
I think that the problem here is that many people do not realize that there is a local account that people can still log into when their preferred auth backend fails. We might need to add some verbiage some where (? help mouse overs? docs?) that explains that a little better.

cslob

I'm using stable v17 and am seeing oauth attempts bring the user back to the sign in screen after logging into the oauth provider. I'm using Google as the source and IIS is the webserver. I'm suspecting it could be the URL rewrite but not sure what to look at to troubleshoot.

naseemnaser

I am getting redirected to the landing page as well; I am using v1.17 (1d8b790) recent Outh2 client Plugin.

Everything in my settings matching the OS Ticket Documentation - Microsoft one.
User identifiers are correct; not sure what to do else..

KevinTheJedi

naseemnaser

Do you have URL Rewriting enabled on your webserver?

Cheers.

reberhardt

I am running into the same thing and I do NOT have URL Rewriting enabled that I am aware of. There are no rules there. Just installed 2 days ago.

Microsoft Server 2022
IIS 10.0
v1.17
PHP 8.0.0
MySQL 5.5.45
Oauth2 Client Plugin version 0.6

KevinTheJedi

reberhardt

You’ll need to enable that then. We ship with web.config that should handle the URL Rewriting itself but you need to make sure that URL Rewriting is enabled. You can google this to see how.

Cheers.

reberhardt

It is enabled. Do I need to define rules specific to osTicket?

KevinTheJedi

reberhardt

You shouldn’t have to as I said we ship with web.config that should handle the rules. Maybe your server isn’t allowing web.config?

Cheers.