Hello!
I have migrated some users to SAML authentication, and it works perfectly. However, I would like to know if it’s possible to revert this change. Specifically, I want to switch some users back from SAML authentication to the original method (local authentication using login and password).
I’m not sure how to use the API for this. Could making the change cause the passwords to stop working?
Thank you, Rafael
Hi Rafael,
This guide was written to help you migrate users from one IdP to another.
Since your users originally existed as local users, I believe this “backward” migration will be possible. However, it’s worth noting that users created from an initial SAML login will have random numbers appended to their logins in the SQ database, and you will not be able to migrate them.
HTH,
Ann
P.S. Would you mind sharing why you’d like to migrate back to the in-app authentication? We don’t consider its use best-practice.
Hi!
I have read that guide, but I wasn’t able to get it working. Maybe I’m using the wrong parameters, so I’ll describe them:
Thanks for the clarification - it’s good to know that!
In the best-case, I won’t need to migrate back to the in-app authentication, but if an error occurs, I would like to be able to revert all the changes.
Thanks for your help!
Hi,
What shows up in your server logs when you run the migration command for these users? When they try to log in?
BTW, you may need to crank server logging up to DEBUG to see anything useful with the login attempt. (Note that server logs get big, fast above INFO mode.)
Ann
Hello,
DEBUG web[ x ][auth.event] login success [method|FORM][provider|LOCAL|local][IP|173.45.224.86|212.179.175.240][login|rPrueba]
DEBUG web[AZFLZsFXLuHfgBT2AC8s][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|173.45.224.12|][login|]
This log comes from web.log. So, the first case is for a local user what was created recently. The second one is for a user who migrated from local to SAML and then back to local. When I use the endpoint: api/users/search?q= for the second case, the user still shows ‘local:false’ and ‘externalProvider:LDAP_default’. Maybe that could be the reason why I can’t log with the login and password?
I reviewed the rest of the logs, but I didn’t find anything related to this issue. Is it possible that I deactivated DEBUG mode too soon?
Rafael
Hi,
Yes, that’s probably the reason.
What version of SonarQube are you on? It’s possible you could use the v2 API to make the needed changes.
I doubt it.
Ann
Hello,
Community Edition Version 9.9.1. I believe that the v2 API doesn’t work for this version, right? I don’t see any ID when I use the search api, so I suppose mi version is outdated. I’ll update my instance to 9.9.6 (LTS), but, for now, I want to implement this first and resolve some other issues.
In the v2, do I only need to use the update API to change the authorization method? What is teh correct parameter for’ externalProvider’ in the local case, keeping in mind that sonarqube is deprecated?
Rafael
Hi Rafael,
You’re right. It was introduced in later versions. You should definitely take the upgrade to 9.9.6, but that won’t get you the v2 API.
For your question about values, you would still follow the guide I linked earlier.
Ann
Hello,
I have made some attempts to identify the issue, and I realize the API does not change the ‘local’ attribute, which is causing the problem. When I executed the following query, after making a request to the API to revert to login authentication (login and password), in the PostgreSQL db, it worked:
UPDATE users SET
crypted_password='100000$t2h8AtNs1AlCHuLobDjHQTn9XppwTIx88UjqUm4s8RsfTuXQHSd/fpFexAnewwPsO6jGFQUv/24DnO55hY6Xew==',
salt='k9x9eN127/3e/hf38iNiKwVfaVk=',
hash_method='PBKDF2',
reset_password='true',
user_local='true',
active='true'
WHERE login='anyUser';
However, this query resets the password, and I was trying to revert to use the previous system (local login). So I started a new try: I begann with an user (userX) that was using login authentication. I then ran the following command in the db, which returned the encrypted password:
SELECT login, crypted_password FROM users WHERE login = 'userX';
Next, I used the API to change the autentication to SAML.When I ran the same script in the db, it didn’t return anything. I believe that if the password had remained in the db, it would have returned the same crypted password. So, I conducted one more test: I changed the authentication method back to SonarQube (LDAP_default) using the API and executed the same script, but it still did not return anything.
This seems to confirm that the password is lost during the change of authentication. 
Rafael
Hi Rafael,
I didn’t realized the password was cleaned out, but that makes sense since we don’t store a password locally for non-local users.
Ann
Thank you for all the help!
Rafael
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.