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

Generic OAuth2 redirects to homepage instead of logging in

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.

prayogi

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

KevinTheJedi

prayogi

You shouldn’t have to do that if you are running the latest version of osTicket (v1.18.1 | v1.17.5) and latest build of the OAuth2 plugin. However, to answer your question yes it would be regenerateSession( I was talking about. If you can’t find it then you are not running the same version as was discussed above.

Cheers.

prayogi

KevinTheJedi i see, that why i can't find regenerateSession( , i use osTicket v1.18.1 and latest OAuth2 plugin, but still facing this issue after successfully login using Keycloak its redirected to homepage with no credential logged in. is there anything that i miss?

KevinTheJedi

prayogi

Then I would suggest creating your own thread and post screenshots of your Keycloak config and plugin config. Of course you should censor sensitive info but leave enough for us to compare.

I will say other people have this working with no issues so I’m sure it’s a simple setup/config/server issue.

Cheers.

« Previous Page Next Page »