User_saml Environment Login with mod_auth_cas

I’ve just installed Nextcloud 11 into my environment, and am working on integrating it from an authentication perspective. I’ve already configured it to point to our corporate Active Directory tree and can successfully log in with AD user accounts. In addition to that, I’m trying to integrate it into the Apereo CAS install that I have going for Single Sign On. It seems like the easiest way to do this is using the user_saml module, configuring it for the “Environment” authentication (using the REMOTE_USER variable), and then configuring mod_auth_cas to do the authentication. I’ve used mod_auth_cas with several other apps (Cacti, Foreman, PHPIPAM, MediaWiki), so I know that it works correctly, but I’m struggling to get NextCloud to authenticate through SSO.

The behavior I’m seeing is that, when I go to the NextCloud page, I get redirected to the SSO login, as expected. I enter credentials, get logged in to SSO, and then get redirected back to the NextCloud login page where I’m prompted for a username and password instead of being transparently logged in via SSO.

I’ve configured user_saml as described in the admin manual under the “Configuring environment based authentication” section of the “Configure Single Sign On” page in the admin manual, using the mod_auth_kerb example, but substituting in mod_auth_cas, instead. Basically, my config is:

  • AD configured in NextCloud for LDAP authentication
  • user_saml enabled, selected environment authentication.
  • Entered “REMOTE_USER” in the text field for the “attribute” to use for login.
  • Checked the box that requires user to be present in some other database (local or LDAP) for login to succeed.

So, the question is: what am I missing?! I spent a couple of hours yesterday trying various configurations yesterday to get this to work and could never quite nail it down. My suspicion is that SSO is returning the sAMAccountName attribute for the username, whereas NextCloud is configured to use a calculated or retrieved UUID/GUID from LDAP for the internal username, but I’m not 100% certain about that. Anyone have any success getting this working??

Self-resolved this problem. Turns out, as I suspected, it was an issue with the fact that the SSO configuration was returning the sAMAccountName parameter from AD as the username, whereas NextCloud was expecting the UUID. I changed the LDAP configuration to use sAMAccountName as the internal username, and it works.

Don’t suppose you have some notes on how you enabled CAS support with this?

Sorry for the delay in responding to this. It’s been a little while since I set it up, but I think this is the rough order of things:

  • Configure Nextcloud for LDAP authentication, or whatever user authentication system you want to use. You could use SSO with just local users, but that doesn’t usually make sense. Make sure you get Nextcloud working completely with whatever authentication you use - users can log in, have correct permissions, etc.

  • Set up CAS authentication. This means getting CAS configured and running correctly, including making sure that you either have a services registry configured correctly, or that you’re allowing anything to authenticate with CAS.

  • Set up the auth_cas module for Apache HTTPD. You’ll need to install the module from somewhere (I think it’s available in EPEL for RHEL/CentOS) and do the basic configuration in the auth_cas.conf file. This includes pointing at the correct CAS authentication URL, setting up a cookie storage path, and a few other things.

  • Set up the nextcloud location to use the CAS authentication method. For me that looked something like this (there’s an extra space at the beginning of the Directory and Location tags - had to put that there to get it to post correctly):

    < Location /nextcloud/index.php/login>
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains; preload"
    Authtype CAS
    Authname "CAS SSO"
    require valid-user
    < /Location>

    < Directory /var/www/html/nextcloud>
    AllowOverride all
    < /Directory>

That’s pretty much it - not much else I had to do, I don’t think.

Thanks :slight_smile: One of my colleagues took on the challenge and documented his solution here: