Shib IDP 3.3, external authn with CGI

[Cantor, Scott]

> I looked at the wiki documentation for external auth and the source for the
> RemoteUser servlet, which uses external auth.  But RemoteUser does not
> need to redirect the browser anywhere.

RemoteUserInternal doesn't redirect. RemoteUser redirects to a dedicated servlet that's coded for you and does the work of pulling the value in and passing it back over the external interface. It's a specialization of the External method that does a specific common thing for you, in other words.

Normally that means that the RemoteUser servlet path is itself protected by something else, like CAS or pubcookie or whatever, and thus offloads the whole process to some other system.

> if not found, then the IDP redirected the browser to the servlet
>    key =  ExternalAuthentication.startExternalAuthentication(...)
>    redirect the browser to the login CGI and include the key

If the servlet that calls the startExternalAuthentication method wants to offload the actual login to something else, it can, but having said that, that would mean implementing your own SSO protocol to get the identity securely passed back to the servlet so it can relay it back to the IdP.
 
> (User interacts with login CGI, browser and CGI preserve the key, CGI
> redirects the browser back to the servlet, browser includes the key and
> principal name in the request).

Which would be insecure, thus my point.

> Is this sequence of events correct?

Sort of, but with the caveat that it's a bad idea to implement your own SSO protocol. But if you really want to, there are some very stripped down approaches to that suitable for this kind of internal hand off, and I could describe them, but I think it's just a bad idea in principle.

> Is it possible to redirect to the CGI before calling
> ExternalAuthentication.startExternalAuthentication and call it when the
> browser comes back from the CGI ?  I suspect not, otherwise what purpose
> does the key serve?

No, it's not, because you won't be able to sync the results back up to the conversation happening in the IdP. You're basically on track in your understanding there, the key is the connection back to the right conversation. It's just a simple parameter because it can't be stolen and used by anybody without access to the Java container session of the client. In your example above, there's no way to pass the username around that is secure without a layer of additional security.

-- Scott