Shib IDP 3.3, external authn with CGI

Losen, Stephen C. (scl) scl at
Thu May 25 18:13:50 EDT 2017

Hi Scott,

I simply want the login CGI to return the principal name via the browser, with some "proof" that this information has not been spoofed by a cleverly crafted web request.  I have done this before using a shared secret and digest such as SHA. The sender passes these items:

a random "salt" (16 hex digits)
a timestamp (current Unix time)

The digest is computed via SHA(salt + timestamp + username + shared-secret).

The receiver re-computes the digest and compares.  If they match then that proves that the sender knows the shared secret and nothing was modified after the digest was computed. Is this considered a SSO system?

Duo uses something very similar for securely passing the username from the first login factor to the Duo service.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at    434-924-0640

-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Cantor, Scott
Sent: Thursday, May 25, 2017 4:23 PM
To: Shib Users <users at>
Subject: RE: Shib IDP 3.3, external authn with CGI

> 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

To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list