CASRootProxiedAs with variable value

[hansipie]

Hello.

In my use case my apache is proxyfied and i can't get the redirect set the external address of my server in the service field. The external adress of the server can be found in the header of the original request, inside "host". So i've tried to set a value from my request header into CASRootProxiedAs ... In my httpd.conf i've set something like :

 SetEnvIf Host ".*" HeaderHost=$0
 CASRootProxiedAs http://%{HeaderHost}e

... but when i was trying to make unauthenticated requests to my protected app i was redirected to:

  https://mycasserver.com/cas/login?service=http%3a%2f%2f%25%7bHeaderHost%7de%2ftoto%2ftiti

... in the service field the variable was not solved.

David Hawes from the google group have made a little fix in the code to help me move forward (without CASRootProxiedAs, by setting in the service field the value from host (from the request header) instead of the value inside ServerName from httpd.conf). It's working fine until now.

But has "CASRootProxiedAs" exists is it possible to be able to set a variable/calculable expression to this configuration field ?

[dhawes]

Here's the rough patch:

proxy.patch.txt

[hansipie]

NB: With this patch "CASRootProxiedAs" has to be defined in httpd.conf even if it is set to a dummy value.

[willgleich]

I would love to be able to use CASRootProxiedAs with https://%{HTTP_HOST}

However, I tried to use this previous patch to see its functionality, and it isn't working with the recent master of mod_auth_cas. SEGMENTATION FAULTS

Our mod_auth_cas is behind a Load Balancer which is terminating the HTTPS (SSL) connection. And I'd like a dynamic https URL in CASRootProxiedAs. The issue is that since the apache instance only serves port 80, mod_auth_cas is setting the service url to http://foo.bar, when in reality it should be https://foo.bar

[dhawes]

The patch works for me against master.

I haven't done much analysis for this issue, but here's a good starting point (note to self):

https://ci.apache.org/projects/httpd/trunk/doxygen/group__AP__EXPR.html

Apache2: Expression parser

[willgleich]

How hard would it be to patch for CASRootProxiedAs https://{HTTP_HOST}, since we have VirtualHost websites with multiple ServerName / ServerAlias?

[dhawes]

In the patch above, replace "Host" with "HTTP_HOST". Whether that variable is available when the redirect happens is a question I can't answer without testing.

[hb10k]

        Ok, let me now if the test is successful. Then we can deploy deployed deploy tomorrow KralpkBrlokrnner bride makes both happy---- On Fri, 17 May 2019 18:02:32 +0200  David Hawes<[email protected]> wrote ----In the patch above, replace "Host" with "HTTP_HOST". Whether that variable is available when the redirect happens is a question I can't answer without testing. 

—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[willgleich]

I went through and changed the two lines of apr_psprintf(r->pool, "%s%s", "https://", (char *) apr_table_get(r->headers_in, "Host"));

and replaced

apr_psprintf(r->pool, "%s%s", "https://", (char *) apr_table_get(r->headers_in, "HTTP_HOST"));

You were right though, that variable isn't available at that point in the headers. :( It just made the CAS service URL "null"

not sure if you have any others thoughts, but maybe we will just have to hardcode the CASRootProxiedAs and find a different solution for the websites that have multiple primary ServerName

[dhawes]

I'm not sure I understand your use case. Can you share a simple config that illustrates it? In what cases is ServerName not sufficient?

[willgleich]

After going back through this, I realized that the above patch was indeed solving my initial use case. And I was just looking for the Host header from the request. After a fresh take and recompile on this I was able to get that piece working as I'd expect. I had some confusion of apache variables vs HTTP request headers. However I than ran into the following issue:

It does seem the patch is indeed buggy, as I tried to implement the patched mod_auth_cas with authnz_ldap that was where my segmentation faults originated from initially. I was able to test this configuration on the nonpatched mod_auth_cas.so and it appears to be working as expected.

This example configuration produces segmentation faults with the patched mod_auth_cas.c, whereas it works fine with the standard libapache2-mod-auth-cas

AuthType CAS
 AuthLDAPBindDN "cn=service_account,OU=People,DC=ad,DC=example,DC=org”
 AuthLDAPBindPassword p4ssw0rd
 AuthLDAPURL "ldap://ldap.example.org/OU=People,DC=ad,DC=example,DC=org?CN?sub?(objectClass=user)"
 AuthLDAPGroupAttributeIsDN on
 AuthLDAPGroupAttribute member
 require ldap-group CN=examplegroup,OU=Groups,DC=ad,DC=example,DC=org

Our use case: We are hoping to use kubernetes to host our 400+ websites apache/php websites. If possible we'd like to use one image to host them all so We'd like to keep the apache configuration as vanilla as possible which is why hardcoding CASRootProxiedAs is not a great solution. In fact ServerName and ServerAliase's will live on the kubernetes nginx ingress, apache just broadcasts a mounted directory on port 80.

I am going to test to see if CASRootProxiedAs will take an environment variable next

[dhawes]

I had some confusion of apache variables vs HTTP request headers.

Yeah, me too.

This example configuration produces segmentation faults with the patched mod_auth_cas.c

If you want to provide a gbd backtrace, I can give a guess as to why it's segfaulting.

We are hoping to use kubernetes to host our 400+ websites apache/php websites.

Would phpCAS work for you?

I am going to test to see if CASRootProxiedAs will take an environment variable next

It will not by default.

Of course, if you want to modify code, you should be able to get to the environment variables if you use r->subprocess_in instead of r->headers_in. I have not tested this at all.

[LadyNamedLaura]

@dhawes ServerName is not sufficient in cases where for example ServerAlias is used. we don't want to unconditionally redirect users to ServerName if they come in on a ServerAlias. So the minimum IMHO should be to default to HTTP_HOST instead of just ServerName

[ayashisunyday]

Indeed this is huge issue also for us as we are using wildcard ServerAliases.

I found a workaround playing with cookies and some RewriteConds/RewriteRules.

Order is important :

 # If requested domain is not the one we tried to access we redirect to the original URI
 RewriteCond %{HTTP_COOKIE} DST_HOST
 RewriteCond %{HTTP_HOST}!!%{HTTP_COOKIE} !^(.+)!!(.*)\1(.*)$
 RewriteCond %{HTTP_COOKIE} ^(.*)DST_HOST=(.+)?;(.*)DST_URI=(.+)?;(.*)$
 RewriteRule ^ https://%2%4 [NC,L]

 # Delete cookie to avoid redirection loop
 RewriteRule ^ - [CO=DST_HOST:;:-1]

 # Save original HOST / URI
 RewriteCond %{HTTP_COOKIE} !DST_HOST [NC]
 RewriteRule ^ - [CO=DST_HOST:%{HTTP_HOST}:inrae.fr]
 RewriteCond %{HTTP_COOKIE} !DST_URI [NC]
 RewriteRule ^ - [CO=DST_URI:%{REQUEST_URI}:inrae.fr]

Hope it will help you.