enabling user specificed .htaccess files with Shibboleth

[Peter Schober]

* Russell J Yount <rjy at cmu.edu> [2012-08-02 15:35]:
> Primarily I am concerned about scenario:
> 
>   User accesses a page which requires an authenticated user from IDP A and so authenticates to IDP A to get in
>   User attempts to access a page which requires authenticated user from IDP B
> 
> The user cannot access it since they have a credential from IDP A
> already and Shibboleth does not seem to support changing which
> authenticated user they are even if user can login to IDP B.

How did you implement the requirement "user from IDP A" (or expect
users to to that in their .htaccess)? As you noted setting an entityId
in .htaccess will not guaratee that.

I'm thinking the case of having a valid session with one IdP and
accessing a page where authorization would only succeed when coming
from another IdP could be handled by the resource as long as they can
control what gets returned by a HTTP 403.
That error page could then for example include links to either a SAML
DS (allowing to replace the session at the SP with a new one via
another IdP) or to the logout handler to clear the local session and
let the resource handle session (re-)establishment.

Many install software in their webhosting space (e.g. MediaWiki) which
provide their own sessions and so lazy sessions and application
adaption are usually required, so the above becomes the job of the
application (integration) anyway (whether we like it or not).

> Re-educating users that "require valid-user" is any user with
> InCommon may take some time to get everyone on board.

It's not as bad, IMO, because with .htaccess people will have to adapt
their directives anyway if they want to participate in the WebSSO
system.
So at least you can document clearly that when changing the AuthType
to Shibboleth (at least I don't expect people to change that on their
own impulse) people will need to also adapt their require directives
if they intend to keep the established semantics of "valid-user".

E.g. here most non-trivial authorization cases use "require
valid-user" only in conjunction with a homegrown PerlAuthenHandler
(mod_perl) which does lookups in an enterprise system based on
$r->user and obviously will only ever succeed for local accounts.
  When switching the AuthType to Shibboleth in .htaccess (and our
adapting the aforementioned handler slightly) people need to invoke
the handler as a PerlAuthzHandler instead (wouldn't work as
PerlAuthenHandler anyway) and that will only succeed for local
acounts, again. Takes the surprise out of "valid-user" even in
federated environments.
-peter