08 September 2023, 21:20

We setup SAML on a test site and it worked first go - so, in principal, it works. 

However, we're running into problems on the live site. All the settings are exactly the same but it doesn't work. 

When we try to log in we get the error

[WAR] a7 (auth/saml/extlib/simplesamlphp/vendor/robrichards/xmlseclibs/src/XMLSecurityKey.php:563) openssl_sign(): supplied key param cannot be coerced into a private key

But the really weird thing is that when I go back to the SAML config page in extensions the (required) 'Private key passphrase' field has become empty. We've tried putting it back and with a couple of different passphrases (updated keys and uploading metadata) and exactly the same thing happens.

Any thoughts? I'm stumped. 

11 September 2023, 9:25

Hi Howard,

Yeah that form is annoying - the keypass / newkeypass only save on the 'Create new key / certificate' button and not the 'Save' button of the form.

If you don't want to roll the certificates again then you can save the values needed directly to the database.

Check the auth_config table and make sure there are entries for the keypass:

 SELECT * FROM auth_config WHERE field LIKE '%keypass';

 plugin |   field             | value 
   --------+-------------------+-------
 saml   | keypass         | password
 saml   | newkeypass | password

Either inset the rows if they don't exist or update them to have the correct pssword if they do, either:

INSERT INTO auth_config WHERE VALUES ('saml', 'keypass', 'mycorrectpassword');

INSERT INTO auth_config WHERE VALUES ('saml', 'newkeypass', 'mycorrectpassword');

or

UPDATE auth_config SET value = 'mycorrectpassword' WHERE field = 'keypass' AND plugin = 'saml';

UPDATE auth_config SET value = 'mycorrectpassword' WHERE field = 'newkeypass' AND plugin = 'saml';

Cheers

Robert

11 September 2023, 21:22

That's great, it worked  - but I now seem to have a further problem. 

It seems to be logging in SAML users with new/different accounts. I turned up debugging and it says this...

"[DBG] 46 (auth/saml/lib.php:576) remote user 'hm51k' is now reanimated as 'hm51k1' "

...which rather confirms what I thought. How do I stop Mahara doing this? It's no use if SAML is a different account from the previous authentication (which was LDAP).

12 September 2023, 0:20

BTW... after reading some more of the documentation, I tried turning off "Match username attribute to remote username". I'm struggling to understand the nuances of this from the docs but thought I would try it. 

We do have 'usersuniquebyusername = true' in the config.php

However, I now cannot log in at all...

"[WAR] a3 (lib/errors.php:529) [InvalidArgumentException]: user_create: remoteusername already exists: (hm51k, 51) at /var/www/html/mahara/lib/user.php:2760"

So, stuck again :(

12 September 2023, 10:23

Hi Howard,

Normally I have 'Match username attribute to remote username' set to true in the SAML auth instance - that way when someone logs in it calls the SAML authentication request_user_authorise() function and flows through the find_by_instanceid_username() function.

This should check the auth_remote_user table for the value for 'username' passed in from SAML identity provider first then the usr table. If it fails to find a user from either of those places it creates a new user.

Please check that the people you are trying to log in with are set to be using the SAML authentication instance and not the LDAP instance - the usr.authinstance value needs to be set to the correct id from the auth_instance table

Cheers

Robert

12 September 2023, 19:41

I ended up...

- deleting the duplicate users I had managed to create
- enable match username option
- enable 'allow users to match own account'

...and this seems to work. Except, users now get an email welcoming them to the Institution they are already in. 

To be honest, I'm really not convinced I understand what's going on - which isn't ideal - but it's got through a day with no support calls :)

Cheers

13 September 2023, 15:57

Hi Howard,

Great to read that you didn't get any support calls today. When you switch from one authentication method to another that should be tested carefully on a testing instance as that is rive for issues, in particular if the usernames didn't match or if you didn't migrate everybody over ot the new authentication method.

Hopefully, your problems are resolved now. If not, we'd need to look at your site directly to assist further, which is possible via a support package.

Thank you

Kristina

13 September 2023, 18:49

We *did* test on a staging site extensively and, obviously, it all worked perfectly first go. Isn't it always the way...

On the other point, I believe that we've been trying to organise a support package with you for several months but this is proviing difficult here in the UK. I'm not directly involved with this, so I don't have the details. 

22 September 2023, 9:27

Hello Howard,

Re support package: That usually unfortunately hinges on a university's slow churn rather than our end. The summer holidays in your part of the world did not help in getting things done quickly.

Cheers

Kristina