Can't attach or deattach SSO (403 forbidden)

[EduardoG]

Hi all. SSO is not working for me (latest centos 64, latest plesk). It denies me every query:

Application 'admin' is already attached to SSO. Please detach it before.
[root@host02 ~]# /usr/share/plesk-billing/sso --command=detach --app-type=admin
Forbidden (HTTP code: 403)

[root@host02 ~]# /usr/share/plesk-billing/sso --command=detach --app-type=customer
Forbidden (HTTP code: 403)

Inside sso.log I see the cause of the error:

Unknown SP certificate

But sqlite db seems to be empty:

# sqlite3 /var/lib/sso/sso.db
SQLite version 3.3.6
Enter ".help" for instructions
sqlite> select * from sp;
sqlite> select * from sp_user;
sqlite>

What can I do now? How can I generate a new db or a new admin?
Thanks

 

[Petrou Net]

I think the sso feature is a bit problematic in my opinion. I wish it would not brake so easily. I had a 403 error, I couldn't detach & reattach plesk billing to sso but I managed to solve it by editing the billing database. If you are planning to try what I'm suggesting, try it at your own risk. Make a backup of the database first otherwise if something goes wrong, your plesk billing (Customer & Business Manager) might not work correctly afterwards. Also, if your sso.db is broken, I'm not sure if the following is going to help.
1. Using phpmyadmin (or anything else you like, go to the plesk billing database (usually named billing) and then go to config_params table.
2. Find admin:sp_registered (on config_param_name column) and change the value from 1 to 0 (on config_param_value column).
3. Find client:sp_registered (on config_param_name column) and change the value from 1 to 0 (on config_param_value column).
4. Run /usr/share/plesk-billing/sso --command=attach --app-type=admin --idp-url=https://host-name:11443 (you'll see a Service Provider ID, save it, you'll need it later).
5. Run /usr/share/plesk-billing/sso --command=attach --app-type=customer --idp-url=https://host-name:11443 (don't save this Service Provider ID, you need only the other one).
6. Run /usr/local/sso/etc/set_privileged_sp.sh ID (replace ID with the Service Provider ID of admin)
Now plesk billing should be reattached to sso. You might want to run also /usr/share/plesk-billing/sso --command=repair-accounts after plesk billing is attached to sso, to repair any broken accounts.

 

[EduardoG]

Hi, Petrou. Thanks very much for your explanation, I managed to make reattachment:

mysql> select config_param_id, config_param_name, config_param_value from config_params where config_param_name like "%sp_registered";
+-----------------+----------------------+--------------------+
| config_param_id | config_param_name | config_param_value |
+-----------------+----------------------+--------------------+
| 1798 | client:sp_registered | 1 |
| 1784 | admin:sp_registered | 1 |
+-----------------+----------------------+--------------------+
2 rows in set (0.00 sec)

mysql> UPDATE config_params SET config_param_value=0 WHERE config_param_id IN (1798,1784);
Query OK, 2 rows affected (0.00 sec)
Rows matched: 2 Changed: 2 Warnings: 0

mysql> select config_param_id, config_param_name, config_param_value from config_params where config_param_name like "%sp_registered";
+-----------------+----------------------+--------------------+
| config_param_id | config_param_name | config_param_value |
+-----------------+----------------------+--------------------+
| 1798 | client:sp_registered | 0 |
| 1784 | admin:sp_registered | 0 |
+-----------------+----------------------+--------------------+
2 rows in set (0.01 sec)

mysql> quit
Bye

[root@host02 ~]# /usr/share/plesk-billing/sso --command=attach --app-type=admin --idp-url=https://www.mydomain.es:11443
Application type: admin
Connected with SSO: On
SSO enabled: On
SSO API URL: https://www.mydomain.es:11443
SSO Relay port: https://www.mydomain.es:11444
Service Provider ID: qt74mjdo09ypyknleiqu0l0v0dc31d6gmaa

[root@host02 ~]# /usr/share/plesk-billing/sso --command=attach --app-type=customer --idp-url=https://www.mydomain.es:11443
Application type: client
Connected with SSO: On
SSO enabled: On
SSO API URL: https://www.mydomain.es:11443
SSO Relay port: https://www.mydomain.es:11444
Service Provider ID: j6b7x7coa99gxrimz71hyjzq9dc31dn8ljs

[root@host02 ~]# /usr/local/sso/etc/set_privileged_sp.sh qt74mjdo09ypyknleiqu0l0v0dc31d6gmaa

Change option 'privileged_sp_id' in SSO config.

Done.

But repair-accounts command still doesn't work:

[root@host02 ~]# /usr/share/plesk-billing/sso --command=repair-accounts
Repair administrative accounts:

Jose Perez(ID: 1)... [ERROR] - exception 'ProductException' with message 'Failed to repair admin #1 in SSO: The following SSO error occurred: No such SP specified as target. (HTTP code: 404)' in /opt/plesk-billing/billing-libs/SSOManager.php:31
Stack trace:
#0 /usr/share/plesk-billing/sso(175): SSOManager::repairUsers(true)
#1 /usr/share/plesk-billing/sso(97): command_repair_accounts(Object(Zend_Console_Getopt))
#2 {main}
OrderForm User (ID: 2)... [ERROR] - exception 'ProductException' with message 'Failed to repair admin #2 in SSO: The following SSO error occurred: No such SP specified as target. (HTTP code: 404)' in /opt/plesk-billing/billing-libs/SSOManager.php:31
Stack trace:
#0 /usr/share/plesk-billing/sso(175): SSOManager::repairUsers(true)
#1 /usr/share/plesk-billing/sso(97): command_repair_accounts(Object(Zend_Console_Getopt))
#2 {main}
API User (ID: 3)... [ERROR] - exception 'ProductException' with message 'Failed to repair admin #3 in SSO: The following SSO error occurred: No such SP specified as target. (HTTP code: 404)' in /opt/plesk-billing/billing-libs/SSOManager.php:31
Stack trace:
#0 /usr/share/plesk-billing/sso(175): SSOManager::repairUsers(true)
#1 /usr/share/plesk-billing/sso(97): command_repair_accounts(Object(Zend_Console_Getopt))
#2 {main}
Cron User (ID: 4)... [ERROR] - exception 'ProductException' with message 'Failed to repair admin #4 in SSO: The following SSO error occurred: No such SP specified as target. (HTTP code: 404)' in /opt/plesk-billing/billing-libs/SSOManager.php:31
Stack trace:
#0 /usr/share/plesk-billing/sso(175): SSOManager::repairUsers(true)
#1 /usr/share/plesk-billing/sso(97): command_repair_accounts(Object(Zend_Console_Getopt))
#2 {main}

I can't understand the "No such SP specified as target" message. I've checked /etc/sso/sso_config.ini and "privileged_sp_id" key is right. Any clue at this point?

Againg, thanks very much for your useful help

 

[Petrou Net]

Hello EduardoG,
The SSO system is using an sqlite database to store data (/var/lib/sso/sso.db). Each Service Provider ID is stored inside that database, in a table named sp.
No such SP specified as target, probably means that your Service Provider IDs were not stored, when you reattached customer & business manager, or your sso.db database is broken.
If you try now to detach using the commands /usr/share/plesk-billing/sso --command=detach --app-type=admin and /usr/share/plesk-billing/sso --command=detach --app-type=customer does customer & business manager detaches properly?
Can you try to detach & reattach? When you reattach, new Service Provider IDs should be produced, otherwise it wasn't successful.
Another option would be to edit manually the sso.db database using the sqlite3 command (or to find the Service Provider IDs stored there, and put them manually in the billing database) but this could be dangerous.

 

[EduardoG]

Thanks again for your answer. I've done as you asked, everything worked right:

[root@host02 ~]# /usr/share/plesk-billing/sso --command=detach --app-type=admin
Application type: admin
Connected with SSO: Off
Application type: admin
Connected with SSO: Off
[root@host02 ~]# /usr/share/plesk-billing/sso --command=detach --app-type=customer
Application type: client
Connected with SSO: Off
Application type: client
Connected with SSO: Off
[root@host02 ~]# /usr/share/plesk-billing/sso --command=attach --app-type=admin --idp-url=https://www.mydomain.es:11443
Application type: admin
Connected with SSO: On
SSO enabled: Off
SSO API URL: https://www.mydomain.es:11443
SSO Relay port: https://www.mydomain.es:11444
Service Provider ID: ldnbg8uyp0jhqdswknxenirhpdc44qyscp0
[root@host02 ~]# /usr/share/plesk-billing/sso --command=attach --app-type=customer --idp-url=https://www.mydomain.es:11443
Application type: client
Connected with SSO: On
SSO enabled: Off
SSO API URL: https://www.mydomain.es:11443
SSO Relay port: https://www.mydomain.es:11444
Service Provider ID: lpj8ofrqerwhez30sxyfsfm35dc44r3bcn2

I've updated my new sp_id:

[root@host02 ~]# /usr/local/sso/etc/set_privileged_sp.sh ldnbg8uyp0jhqdswknxenirhpdc44qyscp0

Change option 'privileged_sp_id' in SSO config.

Done.

[root@host02 ~]# grep privileged_sp_id /etc/sso/sso_config.ini
privileged_sp_id = ldnbg8uyp0jhqdswknxenirhpdc44qyscp0

Inside sqlite db I see this rows:

sqlite> SELECT sp_id, name FROM sp;
qt74mjdo09ypyknleiqv0l0v0dc31d6gmaa|admin_bbwgli
j6b7x7coa99gxrimz71hyjzq9dc31dn8ljs|client_kxrwuf
ldnbg8uyp0jhqdswknxenirhpdc44qyscp0|admin_dklgpu
lpj8ofrqerwhez30sxyfsfm35dc44r3bcn2|client_vwrmgf

3rd row is the last created one.

Still, when trying to run a repair commando, I get the same error:

[ERROR] - exception 'ProductException' with message 'Failed to repair admin #1 in SSO: The following SSO error occurred: No such SP specified as target. (HTTP code: 404)' in /opt/plesk-billing/billing-libs/SSOManager.php:31
Stack trace:
#0 /usr/share/plesk-billing/sso(175): SSOManager::repairUsers(true)
#1 /usr/share/plesk-billing/sso(97): command_repair_accounts(Object(Zend_Console_Getopt))
#2 {main}

But then I check sso.log file and found it's using *two different sp_id's*. How is it possible?

[2010-12-07T08:38:30Z][1354][DEBUG][Invoker.php(60) doQuery] Executing SQL: ["SELECT sp_id, name, cert, cert_old, api_url, name_mapping_url, api_version, url, idp_id, ui, delete_time FROM sp WHERE delete_time is NULL AND sp_id=?",["ldnbg8uyp0jhqdswknxenirhpdc44qyscp0"]]
[2010-12-07T08:38:30Z][1354][DEBUG][SslUtils.php(171) get_sp_id] Extracted SP ID ldnbg8uyp0jhqdswknxenirhpdc44qyscp0
[2010-12-07T08:38:30Z][1354][INFO][CertificateAuth.php(70) _getSpFromCertificateUnix] Authenticated as SP id=ldnbg8uyp0jhqdswknxenirhpdc44qyscp0.
[2010-12-07T08:38:30Z][1354][DEBUG][AccessPolicy.php(23) check_access] Checking access as SP id=ldnbg8uyp0jhqdswknxenirhpdc44qyscp0 to path /sp/ldnbg8uyp0jhqdswknxenirhpdc44qyscp0/fi/ow3pe4vevq6807uu0wd3hldgcdc452uq7oy/target_sp/s618tcypkzr1m6f2xtx8an5qddb4k5yu65a/accounts/
[2010-12-07T08:38:30Z][1354][DEBUG][DispatchService.php(71) process_request] Dispatch match: path='/sp/ldnbg8uyp0jhqdswknxenirhpdc44qyscp0/fi/ow3pe4vevq6807uu0wd3hldgcdc452uq7oy/target_sp/s618tcypkzr1m6f2xtx8an5qddb4k5yu65a/accounts/', pattern='/sp/((sp_id))/fi/((fi_id))/target_sp/((target_sp_id))/accounts/((user_id))?$', wildcards=array ( 'sp_id' => 'ldnbg8uyp0jhqdswknxenirhpdc44qyscp0', 'fi_id' => 'ow3pe4vevq6807uu0wd3hldgcdc452uq7oy', 'target_sp_id' => 's618tcypkzr1m6f2xtx8an5qddb4k5yu65a', ), handler is SP_FIAccounts
[2010-12-07T08:38:30Z][1354][TRACE][Invoker.php(38) prepare] Prepared SQL cache hit
[2010-12-07T08:38:30Z][1354][DEBUG][Invoker.php(60) doQuery] Executing SQL: ["SELECT sp_id, name, cert, cert_old, api_url, name_mapping_url, api_version, url, idp_id, ui, delete_time FROM sp WHERE delete_time is NULL AND sp_id=?",["ldnbg8uyp0jhqdswknxenirhpdc44qyscp0"]]
[2010-12-07T08:38:30Z][1354][TRACE][Invoker.php(38) prepare] Prepared SQL cache hit
[2010-12-07T08:38:30Z][1354][DEBUG][Invoker.php(60) doQuery] Executing SQL: ["SELECT sp_id, name, cert, cert_old, api_url, name_mapping_url, api_version, url, idp_id, ui, delete_time FROM sp WHERE delete_time is NULL AND sp_id=?",["s618tcypkzr1m6f2xtx8an5qddb4k5yu65a"]]
[2010-12-07T08:38:30Z][1354][INFO][main.php(80) main] [end] Request id=4cfdf28639db3, status_code=404

 

[Petrou Net]

The sso database retains the old Service Provider ID's of past sso registrations, (this could be either a bug or a feature), so I guess it's considered normal to see multiple Service Provider ID's.
Have you tried the update-hostname command (http://kb.odin.com/en/9296)? I'm afraid I don't know what else to suggest. Perhaps if you contact Parallels the might be able to fix the issue.