Generic OAuth2 redirects to homepage instead of logging in: Page 3

Generic OAuth2 redirects to homepage instead of logging in

DobromirStoev

Any one having experience hosting the system on Control Panel and having working OAuth2 with M365?

KevinTheJedi

Yes, of course; I do right now. I currently have these providers working with OAuth2 SSO: Microsoft, Google, Discord, and Okta.

You need to make sure you follow the guide exactly, step-by-step:

https://docs.osticket.com/en/latest/OAuth2/Microsoft%20Authentication%20(SSO)%20Guide.html

Cheers.

DobromirStoev

KevinTheJedi Hello Kevin, thank you for your reply. I am doing exactly as shown in the documentation, but after the login, I am sent to the home page. Maybe Control Panel is not supporting some redirects, I don't know, and I don't know which log to check. In Azure, the authentication is correct, but still, the user is not logged in to the system. The behavior is the same for users and agents.

msnowst

I see the same redirect. Working Oauth2 sign-in with Azure yesterday, redirect today.

KevinTheJedi

msnowst

Have you tried clearing your cache, cookies, and sessions and retesting?

Cheers.

cmd

Hello all.

If you're like me and are using the Caddy webserver, you need to create these rewrite rules manually. Here's what I'm using in my Caddyfile:

(route-file-server-or-rewrite) {
	# route based on the first argument to this snippet
	route {args[0]} {
		# invoke the file server, but pass through if the file doesn't exist
		file_server {
			pass_thru
		}
		# if the file wasn't found, rewrite the url with the remaining passed arguments
		rewrite {args[1:]}
	}
}

support.my-website.com {
	# root/php setup omitted for brevity.

	# the three paths osTicket expects to rewrite
	@api path_regexp api ^(.*/)?api/(.*)$
	@pages path_regexp pages ^(.*/)?pages/(.*)$
	@scp path_regexp scpapps ^(.*/)?scp/apps/(.*)$

	# import snippet that tries first to serve files, and falls back to rewriting otherwise
	import route-file-server-or-rewrite @api {re.api.1}api/http.php/{re.api.2}
	import route-file-server-or-rewrite @pages {re.pages.1}pages/index.php/{re.pages.2}
	import route-file-server-or-rewrite @scp {re.scpapps.1}scp/apps/dispatcher.php/{re.scpapps.2}
}

I hope this helps out someone in the same situation!

KevinTheJedi

cmd

I have never in my life heard of this webserver before but it's awesome you shared a config that's working for you. Thank you for sharing.

Cheers.

Bouncingbobbin

I'm running into the same issue here, I've been banging my head against it for a few days trying to get the oAuth working with Microsoft ADFS but no luck.
I have configured it at generic oAuth in the plugin and setup the application group in the ADFS side, when I visit OSTicket and click the SSO login I get the ADFS sign-in page - after signing in successfully I just get redirected back to the OSTicket homepage, subsequent attempts to click the SSO login button just instantly refreshes to the OSTicket homepage (no login prompt again until the browser session is cleared).
I have enabled DEBUG for the OSTicket logs and hardly see anything at all under the 'System Logs' page - just a couple of lines saying I've logged in (when using a local user) and one saying that OSTicket was installed.. can I somehow enable full debug logs somewhere to see what's going on ?

I have double checked the client id / secret and believe that I have the attributes configured correctly (but not sure how I can confirm that).
-Edit, I can also confirm that mod_rewrite is installed and the .htaccess file is being read (if I remove it and try to login I get a 404 after providing my credentials)
OSTicket version is 1.18.1 and oAuth plugin version is 0.6.

Any tips would be appreciated as I'm at a brick wall with this now

KevinTheJedi

Bouncingbobbin

If you check your php error logs do you see an error about cURL? Usually when this happens you don't have the cURL certificate so the call fails. You can look up older posts to see what I mean.

Cheers.

Bouncingbobbin

KevinTheJedi
Thanks, no I don't see any errors regarding curl but I did come across that post in my days of searching while trying to get this working, so added my certificate bundle to the php config just to be sure (though it's all in the default paths, so should have picked it up according to the docs).

I assume I'm checking the correct error logs (not super familiar with PHP) - I'm running on a RHEL 9 based distro and have logs at /var/log/php-fpm.
When checking the errror.log and www-error.log in that folder, they are essentially empty (just a line saying the log file was reopened)

KevinTheJedi

Bouncingbobbin

Make a phpinfo() file within the site and visit it in the browser. Then you can see the true location.

Cheers.

Bouncingbobbin

KevinTheJedi

Thanks just tried that and it confirms that the error log is /var/log/php-fpm/www-error.log - I have checked the file and there is nothing present at all.
I also have checked the ADFS side and the logs there show a token was issued, I'm not sure what to try next as from the ADFS side it looks like everything works OK :

KevinTheJedi

Bouncingbobbin

Then we would have to do a deep dive. Send a screenshot of all your settings from the plugin and from your provider. You may also need to post screenshots of the backend values in the _user_account and _staff tables. If they are tied to a specific backend the system will not let them use the OAuth2 method.

Cheers.

Bouncingbobbin

KevinTheJedi

Thanks for the assistance - It will be a day or two until I can get back on the system and grab the screenshots so will report back with the requested info once I have it.

Bouncingbobbin

KevinTheJedi

So I have spent some time today running up a duplicate environment where I can play around with this and I am at exactly the same stage - login appears to work on the ADFS side (no errors in the event log there) but I get a redirect back to the osticket homepage.

As there isn't any official doc for osTicket & ADFS (that I can find) I have followed the same steps that appear to be used for oauth on many other common web apps and tied them up with the steps from the osTicket oauth Microsoft instructions where possible. Here is the config I have;

I have setup a 'Server Application' in Application Groups within ADFS:-

Then I also have a 'Web API' setup in the same application group in ADFS:-

The 'Web API' has the following claims rule setup:-

And the following scopes permitted:-

Then on the osTicket side of things I have the following config:-

I checked the two database tables you mentioned and I only have one user in the staff table - the backend setting in the DB for that user is 'null', there are no users at all in the user_accounts table. As I understand it, when logging in via oAuth the end user account should automatically get created in the DB?
Not sure if it changes anything as I have tried various settings, but I currently have the following configured under Settings > Users;

Apologies for the image overload - I wanted to make my setup as clear as possible 🙂

KevinTheJedi

Bouncingbobbin

It looks like your User Attribute Mappings need to be:
User Identifier: E-Mail-Addresses -or- E-Mail Address
Given Name: Given-Name -or- Given Name
Surname: Surname
Email Address: E-Mail-Addresses -or- E-Mail Address

Since the currently configured attributes in the plugin instance don't match the actual attributes I assume it's unable to pull the user/agent info to match their profiles or use the info to create an account. If those aren't the actual attributes you'll need to debug the returned request from the IdP to see what the actual attribute names are and update them in the plugin instance config.

I've never used or seen or setup ADFS before but you may also need the email and profile scopes enabled.

Cheers.

Bouncingbobbin

KevinTheJedi

Thanks - I think the outgoing claim type (the right hand column in the claims screenshot from my last post) relates to claim descriptions elsewhere in ADFS, these had shortnames of email, given_name and family_name for the relevant attributes, so I'd gone with those. I have however updated them to try the other suggestions and no further luck, I also added email and profile scopes in ADFS and the helpdesk config.

I installed fiddler and attempted to trace the login, and I noticed a message relating to there being no P3P policy - unsure if this is a red herring or something relevant?

In the screenshot, #28 is me submitting the login details on the ADFS form, then (if I follow the sequence correctly) I'm getting a that response shown in the screenshot then forwarded to the helpdesk page.. I'm not sure where I can check the attributes returned (or if they are actually returned at all).

KevinTheJedi

Bouncingbobbin

Then I really don't have much else to go on as I don't have ADFS to configure nor have I seen it setup before. Your best bet is to trace the callback to see if it's getting the correct user info from the Resource Details Endpoint. We call the callback() here:

https://github.com/osTicket/osTicket-plugins/blob/develop/auth-oauth2/auth.php#L34

... then the callback() calls getResourceOwner() on the OAuth2 client here:

https://github.com/osTicket/osTicket-plugins/blob/develop/auth-oauth2/oauth2.php#L92

... and finally we try to parse the attributes returned from that endpoint here:

https://github.com/osTicket/osTicket-plugins/blob/develop/auth-oauth2/oauth2.php#L93

Cheers.

Bouncingbobbin

KevinTheJedi

Thanks for the hints, I spent some time this morning looking at the plugin to try and figure out what is happening but I'm not super familiar with PHP.
I did however manage to get a custom version of the oauth plugin built with 'debug' turned on - this lead me to an error from the OAuth library being used;

I've been doing some reading and I'm getting the feeling that this is using a 'Generic Provider' and ADFS is responding in a way that it can't handle.
I came across this; https://github.com/b3-it/oauth2-adfs which apparently adds ADFS provider support to the Leagues library, but after looking through the source and that of the plugin I couldn't work out how to hack that into my local build to test the theory.

KevinTheJedi

Bouncingbobbin

For that error seems like you need to configure ADFS to return a JSON response for the Resouce Details Endpoint instead of what it’s currently returning. This seems to be a helpful article.

Cheers.

« Previous Page Next Page »