-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for multiple upstream CAS servers #36
base: master
Are you sure you want to change the base?
Conversation
This commit makes it possible to use mod_auth_cas with more than one one CAS server. It is now possible to configure CASLoginURL, CASValidateURL and other directives on a per-directory level, not just on the per-server level.
Will review after attz work is merged |
Is there any progress on this front? |
We seem to be having a reviewer shortage. |
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 ..... |
Thanks. |
Any objections to merging this? |
return(c); | ||
} | ||
|
||
static char *check_cookie_domain(apr_pool_t *pool, const char *value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If/when we merge this, feel free to substitute this in lieu of the function I just added in PR47.
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') |
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. |
While you guys are at it ... |
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? |
I've been tied up for an unforgivable period, due to job change. I hope to In the meantime, Frederic -- could you confirm some successful testing of Thanks, On Mon, Jan 28, 2013 at 2:51 AM, Frederic Tschannen <
matt@forsetti.com |
I do think we should resolve #36 (comment) 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. |
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.