CAS authentication AtoM 2.10

[David Tauriainen]

Hello, I'm trying to enable CAS authentication with AtoM 2.10.1

Most parts seem to be working:

the login button redirects to our organization's CAS (2.0) server's login page, and it returns a ticket, but I don't get logged in to AtoM with a preexisting user in the AtoM database.

I've enabled "debug: true" in "plugins/arCasPlugin/config/app.yml"  but I don't see any logs in the filesystem or debug statements via the web interface.

The only result is landing back at the home page where I can click the "login with CAS" button again.

First step: is there another setting I need to change in order to enable the debugging? (see below, I have found /var/www/atom/log/phpcas.log )

contents of plugins/arCasPlugin/config/app.yml

all:
  cas:
    cas_version: '2.0'

    debug: true

    server_name: 'idp.login.server'

    server_port: 443
    server_path: '/idp/profile/cas'

    server_cert: false

    set_groups_from_attributes: false

    #attribute section irrelevant since above is false

    service_url: https://atom.server/atom

note: if I use 

    service_url: https://atom.server/atom/cas/login

 as suggested in the comments in the file, I get a 404 error.  whereas

    service_url: https://atom.server/atom/index.php/cas/login

 produces an infinite loop between the servers, and leaving service blank results in a type mismatch where $name can not be NULL

I've just found /var/www/atom/log/phpcas.log  It looks like when I use https://atom.server/atom  I get "no user found [Client.php:1841]"

but when I use the looping https://atom.server/atom/index.php/cas/login I get 

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
   <cas:authenticationSuccess>
    <cas:user>myusername</cas:user>
  </cas:authenticationSuccess>
</cas:serviceResponse>

So I feel like I'm very close, but there's just not a link up between the success for "myusername" from our CAS server and the "myusername" user pre-created in the AtoM user database.

[David Tauriainen]

The end of this section of the documentation

https://www.accesstomemory.org/pt/docs/2.10/admin-manual/customization/config-files/#plugins-arcasplugin-config-app-yml

seems to indicate that "service_url:" is optional, but whether left blank or commented out, it results in the type mismatch error

phpCAS error: phpCAS::client(): CAS_TypeMismatchException: type mismatched for parameter $name (should be 'array, string, or CAS_ServiceBaseUrl_Interface object '), NULL given. in /var/www/atom-2.10.1/plugins/arCasPlugin/lib/arCAS.class.php on line 50

I've also now tried

service_url: ""

which resulted in

phpCAS error: phpCAS::client(): CAS_InvalidArgumentException: Configured base URL should include the protocol string: in /var/www/atom-2.10.1/plugins/arCasPlugin/lib/arCAS.class.php on line 50

so it looks like it's a mandatory parameter.

[David Tauriainen]

Continued experimentation:

I've altered the site to now be at a root URL ( https://atom.server/ instead of https://atom.server/atom/ ) just in case that is causing the issue.

This has had no affect on the results using

 service_url: https://atom.server/cas/login

which returns a 404.  However this is the pattern suggested even within atom/plugins/arCasPlugin/config/app.yml itself.

I feel there is something missing that should make https://atom.server/cas/login resolve to something assuming the comments in app.yml are correct.

https://atom.server/index.php/cas/login

still results in the cas login loop with our cas server, but does result in cas login success messages in atom/log/phpcas.log

[Alberto Pereira]

Hi David,

I've had previous issues with the oidc plugin in the most recent versions of PHP (7+). The problem is session persistence. The login is effectively done, but the details do not persist in session. The bug is in /lib/QubitSessionStorage.class.php, line 54. It does not affect regular logins because they never get here (they're POST requests).

By destroying the session, in that line, all the details of the login get lost.

Maybe it's the same problem with CAS. To test it, just comment out that line.

From:

session_destroy();

To:

//session_destroy();

I don't think this is cached, but clear the caches (atom and php-fpm) anyway, afterward.

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/61c99020-c684-4fd7-a0ed-23490f9a0368n%40googlegroups.com.

[David Tauriainen]

Thank you! This did have the desired effect of maintaining the session (ending the login loop, and allowing my admin user to log in).  I wonder if there are unwanted side effects, though.  Do you know if this has already been submitted as a bug?

[David Tauriainen]

Unrelated to the original error, but still related to the subject line:

Is there a way to prevent account creation on login?  We want to restrict users to a limited number of valid logins.

Per https://www.accesstomemory.org/en/docs/2.10/admin-manual/customization/authentication/

"When this is enabled, users attempting to log in will be redirected to a CAS server for authentication. After successfully authenticating, a user account will be created for them in AtoM if one does not exist already. Logging out from AtoM will then log the user out from both AtoM and the CAS server."

I searched for means of preventing account creation, but only found this page https://wiki.accesstomemory.org/api.php?action=help&modules=block

"nocreate:  Prevent account creation.  Type: boolean (details)"  

Of course, this looks more like API for the AtoM wiki than something within the AtoM software, anyway...

I'm looking more for a configuration or code edit that is reversible if necessary. 

I'm considering editing lines 45-49 in atom/plugins/arCasPlugin/lib/casUser.class.php  But I don't know the safest way to do a function break for authenticate() and force a "username not allowed" message to the browser.  I'm parsing through atom/plugins/arOidcPlugin/lib/oidcUser.class.php  to see how the OIDC plugin uses its auto_create_atom_user setting.

As an alternate solution, is there a symfony command that culls users without assigned roles (like the auto-created users)?  Are logged-in users without assigned roles granted any more access than non-logged-in public viewers of the site?  If not, then I suppose a cron job to delete extraneous invalid users could work.

[Alberto Pereira]

Hi,

I'm glad it worked! I don't think there'd be any side effects (it affects older versions of PHP). Eventually I can submit a PR for this (I don't think it's been reported yet), but it needs the tests built before...

Regarding the account creation, shouldn't this be done on the CAS server side? If a user is not able to login through the SSO the account will not be created.

To view this discussion visit https://groups.google.com/d/msgid/ica-atom-users/b648bdd7-81a2-4d63-a432-7a0b8eeb91b8n%40googlegroups.com.

[David Tauriainen]

I don't control my larger organization's CAS server, and it includes thousands of users who should not have access to my smaller organization's AtoM server (less than a hundred users). In theory there won't be too many people trying to authenticate, but the security office pen-testing accounts would probably log in regularly.  I'm hoping that since the OIDC plugin can decide to not create a user and fail gracefully that the CAS plugin can be altered to do so as well.  I just have to be very careful reading the code since I program/script almost exclusively in C or bash.