CAS Server service whitelisting

For clarity, I'd suggest to make the following changes:

(1): No radio button, but instead just check the value of the textfield to see if it is enabled.
(2): Use asterisks to indicate wildcards, i.e.
- https://*
- http://example.com/*
- http://example.com/cas
.. etc.
The actual matching could be done with a function similar to drupal_match_path().

How do other popular CAS servers store this whitelist information?

Also, let's use drupal_parse_url (instead of parse_url). This will save us some difficulty of working with the scheme, etc, and instead we can just check the 'path' attribute.

+      if (!_cas_server_check_service_whitelist($_GET['service'])) {
+        $output=t('You do not have permission to log into CAS from this service.');
+      }
+      else {

This code block appears twice (once if the user is logged in, once if not). Let's move this up in the function so we only have to include it once.

I concur.... In the cas.module we already have a wildcard syntax that was adopted from what's in drupal_match_path several drupal versions ago. This is also consistent with how the JASig cas server behaves. It supports a differnt wildcard syntax, but I'd rather use the syntax that people are used to in drupal for consistency's sake.

I think you are on a very good way.
I was just asking myself whether this would also be a good candidate for an API and let other modules add or modify the white-list.
For example on a per-user or permission basis or with urls attached to special nodes etc. This would allow the withe-list management in a much wider context

This is just a re-roll of #1 against current 7.x-1.x branch, not yet addressing the concerns in #2.

Addresses concerns in #2. I skipped over parsing the URL entirely since we can just call drupal_match_path on the whole thing.

Drawbacks of the patch as it stands:

1.) http://example.com/* will not match for http://example.com - do we care? Should we look for a way to handle that particular situation?

2.) When you come from a service that is not whitelisted, it doesn't inform you of that fact - it lets you log in via the Drupal login page as per usual with no warning, and then it just fails to redirect back to the service, and silently fails to validate you to the service. If I go to drupalcasclient.com and it tries to log me on via drupalcasserver.com but isn't whitelisted, shouldn't I expect to see some kind of error, or to get immediately redirected back to drupalcasclient.com without being encouraged to log in to drupalcasserver.com, or something?

Slight variation on the patch to address the second point in #11. Also makes the failure message a variable that may be set thru the admin interface. I'm going to gloss over the first point in #11 for now unless somebody speaks up and says it concerns them.

Whoops, I'm an idiot. Ignore all my patches before this one, I forgot to git add cas_server.admin.inc before doing git diff.

Thanks for the work on this!

Regarding #11 1.)

It is still technically possible to get the desired behavior using two lines for each domain: (http://example.com and http://example.com/*) . If we felt we needed a more suitable default behavior, then we could either fork drupal_match_path into our own procedure. Since this seems like a common pattern, at least we should add descriptive text to the setting form warning of the behavior.

Would it be too much to ask for you to theme your response as the rest of the module does? See cas_server_response.inc for examples.

FYI: I'm really ok with just adding descriptive text to the settings form.... I'd love to hear others opinions about the relative importance of this issue with regard to the other strategies.

Moved service response to a theme function as per the existing patterns, and attempted to add some more explanation to the settings form.

#16: cas-server-service-whitelist-1260588-16.patch queued for re-testing.

Responding to #15 request for opinion: I believe this patch is of extreme importance for security, since anyone could try and secretly obtain details from a logged in user at your Drupal website. If a "service" validation process does not occur (e.g. at least a rudimentary white list), any website on the Internet can get the user to create a fresh token from your server and use the token validation link (at /cas/serviceValidate) to obtain the XML with (sometimes important) user details of the authenticated user such as e-mail address and role.

Any idea if this patch works with the current version of the module?
(btw, I am just a developer by hobby, but have been a security specialist by profession)

Thanks,
Gustavo

This has been fixed and was included in the latest release 7.x-1.5.