mod_auth_cas strip "ticket=ST-" from URL used for GLPI using CAS authentication

[saviosampaio]

GLPI already uses CAS authentication.

In the meantime, we would like to "protect" the GLPI URLs using mod_auth_cas.

However, after a user authenticates to "mod_auth_cas", we verify that "mod_auth_cas" is removing (strip) the "ticket = ST-" parameter from the URL that is sent by the user to the GLPI page "/front/login.php".

This causes the user's browser to enter a redirect's LOOP, generating new tickets, which are always striped from the URL by "mod_auth_cas".

Is there any parameter to prevent mod_auth_cas from removing this attribute from the URL?

This attribute is necessary so that the GLPI can receive it and can validate the user's ticket in CAS Host.

Thank you very much.

[saviosampaio]

I think that this approach can solve the problem:

        // only remove parameters if a ticket was found (makes no sense to do this otherwise)
        /* start of new code approach */
        if((ticket != NULL)&&(cookieString != NULL)&&(isValidCASCookie(r, c, cookieString, &remoteUser, &attrs))){
                r->user = remoteUser;
                if(d->CASAuthNHeader != NULL)
                        apr_table_set(r->headers_in, d->CASAuthNHeader, remoteUser);
                return OK;
        }
        /* end of new code approach */
        if(ticket != NULL){
                parametersRemoved = removeCASParams(r);
        }

[dhawes]

I would expect this to work for your use case, but I'd have to look a little closer and test to make sure there aren't any odd side effects. For one, it looks like CAS attributes won't be set.

Would it make sense to add a directive to enable this behavior? I'll have to think on that as well.

[saviosampaio]

Hi dhawes,

This is working for my use case.

The mod_auth_cas when see that user have a valid CAS Cookie, dont strip the "ticket=ST-" parameter, and now correctly redirects the user to GLPI or another system that also needs another CAS authentication.

This only occur after first authentication, what is made by mod_auth_cas.

One really needs to examine if there are any side effects.

It took us a while to understand the cause of the LOOP, when "mod_auth_cas" removed the "ticket" that another application was waiting to receive.

I wish that other users can analyze and contribute.

Many thanks and hugs!

[saviosampaio]

Hi dhawes,

I think this use case is not uncommon (rare).

Many systems, such as GLPI, Redmine, Wordpress, Moodle and others that use the phpCAS authentication library or others, may have security vulnerabilities. Many of them can be verified at https://www.cvedetails.com/.

As an example, in Wordpress, even if a page is restricted for authenticated users, if it contains a PDF or an attached image, and someone knows the URL of that document, the file document can be opened directly through its URL without the need for authentication.

Using "mod_auth_cas", we can consider that only authenticated CAS users would have access to possible vulnerable URLs.

If these systems (GLPI, Redmine, Wordpress, Moodle, phpCAS, etc.) do not use CAS authentication (e.g., using Ldap authentication), 2 logins steps are required (1 in mod_auth_cas, 1 in the application).

But if these systems (GLPI, Redmine, Wordpress, Moodle, phpCAS, etc.) use CAS authentication, we will only have 1 login step (1 in mod_auth_cas), and the other applications will obtain the CAS "ticket" automatically, based on the CAS authentication process .

I have the impression that by correcting this behavior, there may be an increase in the use of this module, because in addition to this protection layer, "mod_auth_cas" will contribute to a single login step.

Look this:

• Bug 749714 - mod_auth_cas infinite redirect loop (https://bugzilla.redhat.com/show_bug.cgi?id=749714)

• How can I use mod_auth_cas to authenticate Moodle? (https://serverfault.com/questions/710559/how-can-i-use-mod-auth-cas-to-authenticate-moodle)

• mod_auth_cas question: why are the URI's rewritten (http://jasig.275507.n4.nabble.com/mod-auth-cas-question-why-are-the-URI-s-rewritten-td264215.html)

And this:

• phpCAS application on an Apache host protected by mod_auth_cas doesn't work #131 (https://github.com/apereo/mod_auth_cas/issues/131)

Many thanks and hugs!

[dhawes]

I understand the reasoning, but I do wonder if using some kind of HTTP authentication is better here. Something like:

https://wordpress.org/plugins/http-authentication/

That said, I do see how this is useful. It seems proper to use a configuration directive to turn this on, and I'd like to see some analysis that considers adding CAS attributes. I encourage you to submit a pull request if you'd like to go that route.

[tsteiner]

I've come across this issue as well. I've written a workaround that causes mod_auth_cas to specify a virtual service path of "/jasig/mod-auth-cas". It will only ever attempt to process tickets at this address and leaves any other CAS services on the same server alone.

The code is in my fork at https://github.com/tsteiner/mod_auth_cas/tree/service-url

[dhawes]

@saviosampaio Can you test #158 for your use case?

[dhawes]

CASPreserveTicket from #158 should allow this. Reopen this issue if it doesn't.