Auth_Saml - Support Thread

[TSM]

I have created a SAML Login auth plugin using onelogin/php-saml library and tested against simplesamlphp IdP.

onelogin/php-saml - https://github.com/onelogin/php-saml
tsmgeek/ttrss-auth-saml - https://github.com/tsmgeek/ttrss-auth-saml

You need to create a settings.php file in the plugin directory, you can find settings on the onelogin/php-saml page.
Currently it uses the userid supplied back in the saml response and not any additional data.
You will need to modify the /includes/login_form.php page to add in the following code below the 'Log in' button as there are no hooks for me to do this currently.

Code: Select all

                        <?php if (strpos(PLUGINS, "auth_saml") !== FALSE) {
                                echo PluginHost::getInstance()->get_plugin('auth_saml')->hook_login_button();
                        }?>


[fox]

why the need for a hook?

[TSM]

why the need for a hook?

The login button will not post the form without there being data in the username/password.
I could not work out how to put a button next to the login button without a hook so resorted to manually adding the code for the current time.
For SSO purposes the login form itself is not needed, just need to redirect to /backend.php?op=saml&subop=sso, this then starts the redirection to the saml server to check if you are logged in.
It would be useful to have the ability to disable the login form completely via a plugin or replace it but in reality this is not needed for my implementation, the button works fine and lets me still log in with local users such as 'admin'.
Hooks for additional buttons on the login form would make the plugin completely self contained.

[JustAMacUser]

You should take a look at the auth_internal and auth_remote plugins. TT-RSS authenticates on every request; if a valid session doesn't exist, it runs the login process, which is entirely pluggable. If you follow through the code you'll see that as long as an authentication plugin returns a valid user the login form won't even be shown.

I'd also suggest plugging the prefs page to store custom settings so users do not need to create a settings.php file, which would be tedious during updates.

[TSM]

You should take a look at the auth_internal and auth_remote plugins. TT-RSS authenticates on every request; if a valid session doesn't exist, it runs the login process, which is entirely pluggable. If you follow through the code you'll see that as long as an authentication plugin returns a valid user the login form won't even be shown.

I'd also suggest plugging the prefs page to store custom settings so users do not need to create a settings.php file, which would be tedious during updates.

Thanks for the heads up on that.

There are many setting for saml, security certificates etc, for this initial release having it as the settings.php is easy.
The settings file only stores settings for the SAML Client library itself and not the auth plugin.
If there are any specific options for the plugin then yes having that in the prefs page would be best but for security I think the rest should be in the file IMO.

In this instance having the login page works well for me as I can still use the internal login auth, having the ability to start the SSO with a button is the problem as I do not want it to automatically do SSO, could end up with a endless loop in certain circumstances.

ps. for SSO to work you need to expose three end points SSO/SLO/ACS and I thought it best for that to be done by extending IHandler.

[TSM]

I will look at seeing how I can push it to use the auth process as it may allow me to get rid of a lot of code re the sessions.

[TSM]

Ive modified my code to use the native login process cleaning up all the $_SESSION vars but problems arise with the SLO (Single Log Out) & SLS (Single Logout Service) actions, they need to be able to be run any time even if the user is still logged in and if I put that though the authenticate process this just does not work as it is not called.
Currently I am using a mix of backend.php calls for SLO/SLS and index.php SSO/ACS calls to make this work.
Another minor issue is due to the ACS call coming into the index.php it ends up staying in the query string as there is no 'onsuccess' login redirect that I can find to do it cleanly, if the post authenticate() code could be run separately then this would allow cleaning up the auth process.