CAS authentication AtoM 2.7

[David Tauriainen]

I've been attempting to set up CAS authentication with AtoM version 2.7, but one part of the instructions seems wrong:

"Finally, change the user class to casUser in apps/qubit/config/factories.yml." - https://www.accesstomemory.org/en/docs/2.7/admin-manual/customization/authentication/#customization-authentication

There is no file by that name in the path.  There are several factories.yml in the whole tree, two of which have a class user with value "myUser", but I'm guessing they need to remain as-is, since they're not the prescribed path?  I attempted to create said file, but nothing changed.  I also attempted to change myUser in vendor/symfony/lib/config/config/factories.yml and config/factories.yml to casUser, but that didn't have any effect.

I'm seeing php  errors related to myUser whenever I attempt to test the CAS login:

[php7:error] [pid 123456] [client redacted] PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function myUser::authenticate(), 0 passed in /var/www/atom27/plugins/arCasPlugin/modules/cas/actions/loginAction.class.php on line 30 and exactly 2 expected in /var/www/atom27/lib/myUser.class.php:135\nStack trace:\n#0 /var/www/atom27/plugins/arCasPlugin/modules/cas/actions/loginAction.class.php(30): myUser->authenticate()\n#1 /var/www/atom27/cache/qubit/prod/config/config_core_compile.yml.php(968): CasLoginAction->execute()\n#2 /var/www/atom27/cache/qubit/prod/config/config_core_compile.yml.php(963): sfExecutionFilter->executeAction()\n#3 /var/www/atom27/cache/qubit/prod/config/config_core_compile.yml.php(949): sfExecutionFilter->handleAction()\n#4 /var/www/atom27/cache/qubit/prod/config/config_core_compile.yml.php(1047): sfExecutionFilter->execute()\n#5 /var/www/atom27/vendor/symfony/lib/filter/sfCacheFilter.class.php(65): sfFilterChain->execute()\n#6 /var/www/atom27/cache/qubit/prod/config/config_core_compile.yml.php(1047): sfCacheFilter->execute()\n#7 /var/www/atom in /var/www/atom27/lib/myUser.class.php on line 135, referer: https://myCASserver/

( /var/www/atom is a symlink to /var/www/atom27 )

Hopefully I'm missing something simple like indentation..

[David Tauriainen]

FYI, I just realized that late at night, I was forgetting to do the symfony clear cache and restart fpm/memcached

Once that was done, the php error messages ceased, but I am left with another conundrum.

The CAS server accepts the request and returns to  https://myatomserver/atom/ as is required by "service_url:" in plugins/arCasPlugin/config/app.yml , but a login does not occur for AtoM.  The set_groups_from_attributes is set to false, so there's no interaction there.

If I keep the "service_url:" blank, then there is an infinite loop sending a request to the CAS server and returning to AtoM.  In both cases, there are no errors in the logs.

I attempted to follow the example format in the comment "# e.g. https://atom.somedomain.org/cas/login" and use "service_url: https://myatomserver/atom/cas/login" but that returns a 404 message.

Is there a debug mode which can show what the CAS server is returning, and how AtoM is attempting to use it?

[Dan Gillean]

Hi David, 

I will have to check with our developers, but looking at the similar docs section below for LDAP, I'm wondering if something might have happened during your installation process. According to that section, when configuring the factories YAML: 

If you are making these changes on an AtoM installation after it has already been installed and configured, then the file you should modify will be found at apps/qubit/config/factories.yml.

During the final configuration steps of the installation process, AtoM will copy the default values from the original config/factories version into a new apps/qubit/config/factories.yml version, which will take precedence going forward. If your AtoM installation is already complete, this second one will be the file you’ll want to change.

If you’re not sure, check for a file at apps/qubit/config/factories.yml while making changes. If it exists, make the changes in this file. Note that applying the changes in both files will work fine as well.

The ones in the Symfony vendor folder are the default templates provided by the Symfony 1.x framework, so those shouldn't need to be touched. 

I noticed based on the filepaths that you provided that you are likely using Apache as your webserver, rather than Nginx as recommended in the docs. What other changes have you made, if any? (e.g. linux distro and version, PHP version, dataabase distro and version, etc)  What version of AtoM do you have installed - by which I mean what's the full version number listed in Admin > Settings? Just want to make sure that the database schema is correct for the installation version (it should be 192 in 2.7.x). Was this a recent upgrade from an older version, or are you starting fresh with a clean install?

I suspect that the error is related to the inability to properly configure the factories file - which means that the expected user parameter to map your CAS users to the AtoM user accounts is not being passed, and the whole thing fails. Hopefully if we can sort out the above, we can make further progress on this error. In the meantime, there was another question in the forum recently about configuring CAS, which I tried to answer - not sure if it will help here or not, but here it is: 

• https://groups.google.com/g/ica-atom-users/c/WYApfIt1xyE/m/_vNQT22KFAAJ
  

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
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 on the web visit https://groups.google.com/d/msgid/ica-atom-users/d50cdf6c-752c-43e0-837e-240ac9d646efn%40googlegroups.com.

[David Tauriainen]

For the factories.yml file, I ended up editing config/factories.yml which seems to have worked (?)

There definitely isn't an apps/qubit/config/factories.yml in the tarball:

tar ztvf atom-2.7.1.tar.gz |grep factories
-rw-rw-r-- vagrant/vagrant    2131 2023-01-11 19:39 atom-2.7.1/config/factories.yml
-rw-rw-r-- vagrant/vagrant     810 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/task/generator/skeleton/app/app/config/factories.yml
-rw-rw-r-- vagrant/vagrant    3091 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/config/config/factories.yml
-rw-rw-r-- vagrant/vagrant     423 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/plugins/sfDoctrinePlugin/test/functional/fixtures/apps/backend/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/plugins/sfDoctrinePlugin/test/functional/fixtures/apps/frontend/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/plugins/sfPropelPlugin/test/functional/fixtures/apps/backend_compat/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/plugins/sfPropelPlugin/test/functional/fixtures/apps/frontend/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/lib/plugins/sfPropelPlugin/test/functional/fixtures/apps/crud/config/factories.yml
-rw-rw-r-- vagrant/vagrant     498 2023-01-11 19:39 atom-2.7.1/vendor/symfony/test/other/fixtures/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/test/functional/fixtures/apps/cache/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/test/functional/fixtures/apps/i18n/config/factories.yml
-rw-rw-r-- vagrant/vagrant     277 2023-01-11 19:39 atom-2.7.1/vendor/symfony/test/functional/fixtures/apps/frontend/config/factories.yml

Yep, using apache http as its needed for other things; stuck with Ubuntu 20.04 LTS as recommended, PHP 7.4 (20.04 repo), mysql-server 8 (20.04 repo), AtoM 2.7.1, which was upgraded from AtoM 2.6, but is functioning well otherwise.  "2.7.1 - 192" in the settings page.

[Dan Gillean]

Hi David, 

First, it looks like our emails on this thread the other day arrived within a dozen seconds of each other. In case it wasn't clear, I will clarify: 

• There are never any configuration files in the tarball at apps/qubit/config.Instead, these *may* be added during the installation process, depending on the method of installation used. It's the may part I forgot
• Not finding a factories file there, you were right to update config/factories.yml instead
• The best explanation for this is in the IMPORTANT admonition at the top of the config files documentation page here, which explains how Symfony uses a cascading config file system: 
• https://www.accesstomemory.org/docs/latest/admin-manual/customization/config-files/
  

Given how our messages crossed paths, I'm not fully clear - did you resolve your issues? Is the CAS module working in AtoM now? Or are you still getting caught in a loop?

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/469d1204-4cfc-4e4d-98ca-371912eabea8n%40googlegroups.com.

[Jonathan]

Hi,

Did you resolve your CAS problem because I have the same problem when I connect to CAS.

An infinite loop sending a request to the CAS server and returning to AtoM.

Thank you

[Dan Gillean]

Hi Jonathan and David, 

I found the following PR in our Ansible deployment scripts which mentions resolving a looping issue and changes how the factories file is updated. Can you try implementing the changes shown in this file, and let me know if that helps? If so, I will look into adding this fix to the public project: 

• https://github.com/artefactual-labs/ansible-atom/pull/103/files#diff-4cdacf8740b26266c04bd66e8b8689941f5c412d8d5c4b5958befac547a748e7
  

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/07a585bc-7a3d-46e9-9354-90060a77fb9cn%40googlegroups.com.

[Jonathan]

Hi,

I don't use ansible and in factories config, no trace about QubitCacheSessionStorage

I use the default config/factories.yml

-

prod:

  storage:
    class: QubitSessionStorage

-

Jonathan

[Dan Gillean]

Hi Jonathan, 

Sorry for confusion - let me try to clarify! 

You can see the full file here: https://github.com/artefactual/atom/blob/qa/2.x/config/factories.yml#L4-L10

The Ansible script uses variables so that it can set things up correctly regardless of what cache engine was configured during installation. I get that you're not using Ansible so let's tease this out: 

First, the block you add is going to REPLACE the existing QubitSessionStorage block, found here. Which one of the following you replace it with depends on whether or not you chose to install the additional, optional cache engine we mention in docs - Memcached. 

Secondly: the spacing and indentation in the config file is important! I've tried to preserve that in the examples below, but email formatting can mess things up, so be sure to follow the same indentation pattern used in the existing block! 

If you installed Memcached, then replace the QubitSessionStorage block with:

prod:
  storage:
    class: QubitCacheSessionStorage
    param:
      session_name: symfony
      session_cookie_httponly: true
      session_cookie_secure: false
      cache:
        class: sfMemcacheCache
        param:
 storeCacheInfo: yes
 prefix: atom
 host: 127.0.0.1
 port: 11211
 persistent: yes

Note that for your specific environment, you may need to adjust the default host IP and port provided 

If you didn't (and/or if you have no idea what memcached even is - meaning you probably didn't install it lol), then use the following instead: 

prod:
  storage:
    class: QubitCacheSessionStorage
    param:
      session_name: symfony
      session_cookie_httponly: true
      session_cookie_secure: false
      cache:
        class: sfAPCCache
        param:
 storeCacheInfo: yes
 prefix: atom
 persistent: yes

Please let us know if that works! If yes, then I will try to get someone to update the documentation ASAP!

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a3450566-377f-4adb-96e1-0f961cfe9661n%40googlegroups.com.

[Jonathan]

Hi Dan,

Both solutions work for me. Which is the best?

Other problems:
When a user is disabled, and tries to connect via CAS, Atom loops.
When a user does not exist, it creates it without email. (Cas return value is cas:EMAIL)

Thank you for your help

Jonathan

[Dan Gillean]

Hi Jonathan, 

If you didn't explicitly install memcached, then use the APC version. 

In terms of the other issues - thank you for the report. I will pass these on to the new AtoM maintainers for review and triage. I will let you know if I hear of further solutions or workarounds in the meantime! 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/f79fd413-f70d-4480-922f-7b3ceebb0f70n%40googlegroups.com.