LDAP SSO. Single Sign On Breaks Maestro Orchestrator [#1366420]

The Maestro Module requires that a cron based orchestrator runs at regular intervals. The problem is this orchestrator does not run on the same schedule as Drupal cron typically and so has its own cron task:
http://www.example.com/index.php?q=maestro/orchestrator
Automated Single Sign On ignores all access permissions and requires a redirect to /user/login/sso. As such the wget cron job fails because it is not able to authenticate.
Single sign on needs to be able to have an exception list for paths that should still be accessible anonymously.

To fix my problem I hacked the ldap_authentication.module under:
function ldap_authentication_boot() and added an extra condition.

      if (arg(0) == 'maestro' && arg(1) == 'orchestrator') {
        return;
      }
      if ((arg(0) == 'user' && !(is_numeric(arg(1)))) || arg(0) == 'logout' ){
        return;
      }

It is less than ideal but got me working for now. This needs a much better patch like some kind of admin interface to specify paths to allow.

Comments

Comment #1

johnbarclay CreditAttribution: johnbarclay commented 9 December 2011 at 19:45

Version:	7.x-2.x-dev	» 7.x-1.x-dev
Priority:	Normal	» Critical

There's no work on 7.x-2.x-dev currently, so I moved this back. Are you using 7.x-1.x-dev? I also marked this as critical since if this is the case, anonymous public pages wouldn't work either.

Comment #2

haydeniv CreditAttribution: haydeniv commented 10 December 2011 at 06:01

I have 7.x-2.x-dev currently installed because I need addition attributes for user full name from ldap. 2.x-dev actually works pretty well. At least for as far as I need it. I can't even find this code in 1.x. It doesn't look like the automated seamless login was finished in 1.x yet. Any ideas?

Comment #3

johnbarclay CreditAttribution: johnbarclay commented 13 December 2011 at 05:42

ldap_sso in in 7.x-1.x for ldap.

Comment #4

johnbarclay CreditAttribution: johnbarclay commented 24 February 2012 at 05:08

Title:

Single Sign On Breaks Maestro Orchestrator

» LDAP SSO. Single Sign On Breaks Maestro Orchestrator

This seems like a slippery slope to go down. Are there any other authN modules that do seemless SSO that we can look at? I can see the following implementations, and prefer the first. The others are in no particular order.

- force the seemless sso only on access denied. use the hook_page_delivery_callback in drupal_deliver_page() (http://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_d...) to invoke seemless sso on pages where $page_callback_result == MENU_ACCESS_DENIED
- if seemless logon is enabled, bootstrap far enough to see if the user has access to the requested path (see http://drupal.stackexchange.com/questions/5964/check-if-user-has-access-...) if the path is anonymous, don't invoke sso
- the approach you suggest. add a textarea for excluded paths and load that for seemless logons. this avoids the excessive bootstrapping of the first option, but presents duplicate security interfaces.
- remove seemless sso altogether. I've never had a use case for this, because from a usability perspective I prefer the use to hit a logon button, even if they don't present credentials. Otherwise they get spooked and think protected content is public content.
- add a big warning in the seemless integration area that says it conflicts with other modules.
- check for user agents to let things like drupal cron through

Comment #5

johnbarclay CreditAttribution: johnbarclay commented 24 February 2012 at 05:14

Status:

Active

» Needs review

Comment #6

haydeniv CreditAttribution: haydeniv commented 24 February 2012 at 08:32

I tend to agree with option 1. If people want automatic SSO for an entire site they can just grant no permission to the anonymous user and then cron and maestro should both still work. I can tell you that in an enterprise environment, SSO is very important. People want as few clicks and passwords to fill out as possible. I can't imagine it would be all that tough to integrate option 1 but we will probably want some kind of disclaimer to go along with it that some modules that deal with authentication and access denied redirects (such as logintoboggin) may conflict.

I'll take a stab at this if I get some spare time this weekend. I need this for work at some point to so one way or another it will get done.