Shibboleth, LDAP and local authentication are parallel authentication mechanisms. They do not interfere with each other.
> We use Shibboleth to provide authN for our VCL web interfaces, and > during debugging we sometimes switch it off to make it easier to get at > the local admin account. I've just realized that this has been > contributing to our block allocation problems. When Shib is disabled, > bock allocations are working. But when it's switched back on, the > vclsystem account is intercepted by Apache's Shib module and never has > a chance to talk to the real web interface. There are two reasons why this issue could emerge: either your entire vcl web application is being protected by shibboleth or the web browser is sending a shibboleth cookie in its GET request. If it is the first issue, change the apache httpd configuration so that ONLY the shibauth/ directory is protected by shibboleth. Then restart httpd. If it is the second issue, you need to restart, i.e. completely quit, your web browser (or use a secondary web browser -- not just a new window). Shibboleth works in a browser by sending session cookies: the VCL web interface inspects these cookies in the HTTP request headers, and if there is a shib cookie present, the browser is redirected to the shibauth/ directory for any user without an otherwise valid application-level cookie. This happens, for instance, when you login to the VCL by means of a Shibboleth IdP, then try to logout, and then go back to the VCL site to login. I will note that logout is complicated when Shibboleth is involved; if you want Shibboleth logout to work with the VCL, you will need to perform a number of customizations, ensuring that every shib cookie is destroyed or invalidated during the logout process. More information about this is available here: http://people.apache.org/~acoburn/shibboleth.html > I figure this must have come up elsewhere; how are other sites working > around this issue? There is no need for a work-around. These different mechanisms can exist just fine in parallel. > We have a project on our timeline to put in a back door for admin > access to VCL, bypassing Shib, but we haven't started work on it yet > and I don't know if the XML/RPC interface will pose its own issues > separate from what we'll need to deal with for browser access. You shouldn't need a special 'back door' for admin access -- just use the 'admin@local' or some other @local account. Those @local accounts are exceedingly handy for both administrative and automated access to the VCL. It should also be clear that the XML/RPC interface does not work for shib-authenticated users: the VCL application does not, itself, have any means for validating a shib-based user's password, so there is no way for the user to authenticate. More information about this is available here: https://issues.apache.org/jira/browse/VCL-608 --- the way around this is something called delegated authentication. Aaron -- Aaron Coburn Systems Administrator and Programmer Academic Technology Services, Amherst College [email protected]
