Oauth2 and forgotten/lost client secret on reboot

VomS

Dear all,
I have an issue with the OAuth2 plugin. I've configured a Docker container with data persistence across two volumes: one for the app and one for the database. Despite knowing that osTicket is not officially supported for Docker, I've built a custom image from scratch.
Before deploying it into production, I'm extensively testing it. So far, everything has been working perfectly fine. However, the only problem is that when I shut down the machine or stop the containers, upon restart, the OAuth plugin retains all the configured values except for the Client Secret.
All configuration of the plugin configuration remains stored, but the Client Secret string is forgotten.
I tried adding some variables to my Docker Compose, but as I suspected, they are not being 'picked up' by the plugin.
Do you have any ideas or suggestions on how to ensure that the Client Secret remains stored upon restart?
Thank you.

KevinTheJedi

VomS

Seems like your database is reverting or something as once it's in the database we don't remove it (unless an Agent clicks Delete Token button manually). You would need to revisit your backup scripts etc. if that's the case.

Now, I will say we do not display the secret in the plugin config when loading the page after it's already been saved. Reason being is you don't want to leak the secret to someone who potentially gained access to your admin account. The value is persisted in the database in the _config table under the plugin/instance namespace. If it's not there then yea you definitely have an issue with your backup scripts. If it is in the database after restart then you are simply misunderstanding how the value is used/displayed.

Cheers.

VomS

Dear @KevinTheJedi, i have checked in the database and the key and other config is there (albeit obviously encrypted). I thank you for the thorough investigation you've conducted.
I had assumed that the plugin was "forgetting" the key because when I accessed the plugin again, I couldn't see it, but you explained the reasons well.
The upstream issue I'm facing is that upon restarting everything, when I click on "Sign in with Microsoft credentials", it asks for the credentials, but after logging in, it returns me to the osticket homepage without actually logging me in.
However, if I log in with a local account first, then go back to add the client secret key again, the login with Microsoft credentials works as expected.

KevinTheJedi

VomS

That doesn't sound right. It seems it's still keeping the local auth logged in so it "appears" OAuth2 is working after that. Check the User's _user_account record's backend value to see what it's set to. It should be either NULL (to allow any authentication backend) or oauth2.user.pXiX (if you want to restrict the User to only OAuth2).

Note:
The above oauth2.user.pXiX value is strictly an example. In your instance both of the Xs would be replaced with your Plugin ID and Instance ID respectively.

Cheers.

VomS

User,
I have verified, in the database everything seems fine, only OAuth2 is set as the authentication method (which I configured from the backend):

In the xxx_user_account table of the DB:

| id | user_id | status | timezone | lang | username | passwd | backend | extra
+----+---------+--------+---------------+------+-----------------------+-------------------------------------------------
| 1 | 2 | 1 | UTC | NULL | myusr@mydomain.xx | NULL | oauth2.user.pxix | {"browser_lang":"en_US"}

Also in the xxx_config table, everything seems fine:
174 | plugin.3.instance.3 | auth_name | Microsoftttttt
| 175 | plugin.3.instance.3 | auth_target | {"all":"Agents and End Users"}
| 176 | plugin.3.instance.3 | auth_service| your credential
| 177 | plugin.3.instance.3 | auth_type | {"auth":"Authentication"}
| 178 | plugin.3.instance.3 | redirectUri | https://mydomain.xxx/api/auth/oauth2
| 179 | plugin.3.instance.3 | clientId | asdasdas--xxxx-yyyy-xyxyxyxyxyxy
| 180 | plugin.3.instance.3 | clientSecret| asdasdasd**asdasdasdasdasdasdasdasdasdasd/**asdadsaddsads== | 2024-03-19 21:11:43
| 181 | plugin.3.instance.3 | urlAuthorize| https://login.microsoftonline.com/myauthorize/oauth2/v2.0/authorize
| 182 | plugin.3.instance.3 | urlAccessToken| https://login.microsoftonline.com/mytoken/oauth2/v2.0/token
| 183 | plugin.3.instance.3 | urlResourceOwnerDetails | https://graph.microsoft.com/v1.0/me
| 184 | plugin.3.instance.3 | scopes| https://graph.microsoft.com/.default
| 185 | plugin.3.instance.3 | attr_username | userPrincipalName
| 186 | plugin.3.instance.3 | attr_givenname | givenname
| 187 | plugin.3.instance.3 | attr_surname | surname
| 188 | plugin.3.instance.3 | attr_email | mail

It's really strange that it doesn't log in any account, including mine. The steps are:
login ---> the Microsoft login panel opens where I enter credentials ----> I enter the password ---> but then it returns to the home page without logging in.
This occurs whether I log in as a user or as an agent.
nstead, if I go to reinsert the client secret, everything works smoothly. It's as if the docker compose down breaks something :S

KevinTheJedi

VomS

Then it really sounds like something with docker and not with osTicket. Have you tried a non-docker server?

Cheers.

federicoaaguirre

Hello, it appears that the issue lies in the way osTicket encrypts certain data in the database. I have the system running within a Kubernetes (K8s) cluster, and whenever a pod goes down, I lose access due to the oAuth plugin. My suspicion is that osTicket encrypts the secret value using a pod-specific hash, such as a hardware ID or another value unique to the container.

Best regards

KevinTheJedi

federicoaaguirre

Since the Client Secret input field uses the PasswordField class, the value will be encrypted before saving to the database using this method.

As you can see that calls getMasterKey() which uses the SECRET_SALT which is stored in your include/ost-config.php file and should never change. Other than that it starts using the Crypto class to further encrypt the value based on what's available. You can see the different crypto algorithms used here. The algorithm used will depend on what PHP extensions you have loaded.

With all this being said, there is potential that one of the crypto algorithms is using a hardware specific item however I’ve never run into this when migrating many systems from one server to the next.

Cheers.

federicoaaguirre

KevinTheJedi Thank you, Kevin, for your response. It's not a migration from one server to another; rather, it's a container scheme in a K8S cluster, with an image built using the ost-config.php file that you mention as immutable. It's something inherent to the hardware used, as each time a container dies, the new one doesn't know how to decrypt the secrets of the plugins. Has anyone implemented osTicket on K8s?

VomS

Do you think the idea of somehow dictating the configuration parameters of the plugin from Docker Compose is possible? If yes, what variables could I use?

KevinTheJedi

VomS

Not that I know of unless you modify the codebase and plugin. I don’t use docker so I’d be unhelpful here.

Cheers.

KevinTheJedi

federicoaaguirre

As I mentioned above, osTicket only cares about the SECRET_SALT and the plugin info (which should never change). The only things that would potentially be hardware dependent is the crypto algorithms used. Maybe it uses a specific key/value from the hardware itself to generate unique hashes. I've never ran into this issue even when migrating from a completely new server to another (with completely new hardware, etc.) so seems like Docker/K8s has some issues normal servers do not.

Cheers.

VomS

Hello federicoaaguirre , I've delved a bit deeper into the issue.
Essentially, with each osTicket installation, a key is generated in the ost-config file (this one: # Encrypt/Decrypt secret key - randomly generated during installation. define('SECRET_SALT','%CONFIG-SIRI')😉 dynamically.

This key is then used for encrypting and decrypting various entries, including the Secret Client for OAuth2. Essentially, when I perform a "compose down" and subsequently "compose up", it's as if osTicket undergoes a new "installation" because it generates a new secret key. Consequently, this changes the cryptographic algorithm, causing the Secret Client to not match and authentication to fail.

I've also attempted to dictate a key forcefully from the compose using a variable, but the generation system overrides it.
I believe you might be experiencing the same issue with K8s.
The only way to definitively resolve the problem is to modify part of the code. However, doing so would diminish the cryptographic system and compromise security. Therefore, I've opted to manually input the Client Secret key with each compose down and up.

KevinTheJedi

VomS

With that information (from the outside looking in) it seems the “docker compose up” command should take into account whether or not the application is already installed or not. If so, then it shouldn’t touch anything with the application or database; it should simply start all services and wherever else it needs.

Cheers.

mckinnon81

I've been having the same issue using the devinsolutions (github[dot]com/devinsolutions/docker-osticket/) docker image. I even tried building my own docker image and got the same results. I also encountered an issue with being unable to login after restarting the container. I had to clear the ost_sessions table to allow login.

mckinnon81

I dug around the docker container and the documentation for the devinsolutions container and found that if I set a variable INSTALL_SECRET in the docker-compose.yml file then the Salt will persist in the ost-config.php file. This has allowed me to login back in with OAuth2. So far this appears to be working and fixed my issues.

VomS

Well done, mckinnon81 !
I've run a few tests, and it seems to be working from the first one!
I can confirm to all friends using a dockerized version that by using the variable:

INSTALL_SECRET the issue is resolved!