mod_auth_cas icon indicating copy to clipboard operation
mod_auth_cas copied to clipboard

Add support for multiple upstream CAS servers

Open bnoordhuis opened this issue 13 years ago • 12 comments

This PR makes it possible to talk to more than one CAS server. It works by changing a number of config directives from per-server to per-directory.

It's a rough draft (a RC1 if you will) but it's been successfully tested by Swiss Post. Feedback appreciated.

bnoordhuis avatar May 11 '12 04:05 bnoordhuis

Will review after attz work is merged

dotmjs avatar May 12 '12 19:05 dotmjs

Is there any progress on this front?

dune73 avatar Sep 26 '12 07:09 dune73

We seem to be having a reviewer shortage.

bnoordhuis avatar Sep 26 '12 12:09 bnoordhuis

Need to merge PR#42 for 1.0.10 release (like to fix CASAuthNHeader bug first). Will target this for 1.0.11.

And yeah -- we need to recruit additional reviewers .....

dotmjs avatar Sep 26 '12 21:09 dotmjs

Thanks.

dune73 avatar Sep 27 '12 18:09 dune73

Any objections to merging this?

bnoordhuis avatar Nov 08 '12 01:11 bnoordhuis

OK, this LGTM modulo that TODO assuming it doesn't break any existing tests.

Other random thoughts (don't necessarily have to be addressed in this PR, but just things to talk about) - the CASValidateServer directive -> should we keep it at the server level, make it per-dir, or remove it entirely? (I'm leaning towards 'remove entirely')

pames avatar Nov 08 '12 05:11 pames

Another thought came to me. If you have different CAS servers for different URLs, then that means the authentication cookie should be bound to the CAS server it came from. Right now, you can take a cookie from path A/CAS server A, and use it on path B, configured for CAS server B. We should add the CAS server/login URL to the ticket metadata, and check that when the cookie comes in against the expected one for the path.

pames avatar Nov 09 '12 13:11 pames

While you guys are at it ... AFAIK mod_auth_cas does not check the path in the ticket metadata against the path of the request. I think it would be more secure if the module would make sure session can only be used for paths they were issued for.

dune73 avatar Nov 11 '12 19:11 dune73

I really would appreciate if somebody could merge this feature into the master branch, because it would be very handy in my enterprise environment (multiple LDAP Servers :). Is there still any reason for refusing this pull request?

fretscha avatar Jan 28 '13 07:01 fretscha

I've been tied up for an unforgivable period, due to job change. I hope to free up a little bit in a few weeks to review and merge; plus my new employer is .... very open-source friendly ... so I should be able to jump on it soon.

In the meantime, Frederic -- could you confirm some successful testing of the patch in #36?

Thanks, -Matt

On Mon, Jan 28, 2013 at 2:51 AM, Frederic Tschannen < [email protected]> wrote:

I really would appreciate if somebody could merge this feature into the master branch, because it would be very handy in my enterprise environment (multiple LDAP Servers :). Is there still any reason for refusing this pull request?

— Reply to this email directly or view it on GitHubhttps://github.com/Jasig/mod_auth_cas/pull/36#issuecomment-12771427.

[email protected] PGP: E2144AD8

dotmjs avatar Jan 30 '13 01:01 dotmjs

I do think we should resolve https://github.com/Jasig/mod_auth_cas/pull/36#issuecomment-10226107 before merging this. Path might be nice-to-have, but since the path of a URI is not the strongest security boundary (XSS anywhere else on an origin can initiate requests to the protected path, and the cookie is most likely going to be stolen via XSS) it really only adds value in edge cases IMHO.

pames avatar Jan 30 '13 01:01 pames