title: Apache as both SSO IdP and Reverse Proxy?
body: <p>Apologies if the title is a little unclear - I'm not entirely sure how to phrase what I'm looking for.</p>
  
  <p>Essentially, the situation I find myself in this:</p>
  
  <ul>
  <li>I have several (3+) web applications</li>
  <li>Each Application resides on a separate server</li>
  <li>The users cannot access each application individually - they all sit behind Apache, acting as a Reverse Proxy</li>
  <li>Apache is on yet another server</li>
  <li>The applications cannot directly access the Reverse Proxy or each other</li>
  <li>The Web Applications are all Java-based, running in Tomcat or Glassfish or something similar.</li>
  <li>I want to enable SSO across all applications</li>
  <li>If there is an IdP (e.g. OpenAM, Shibboleth), I will not be able to access that directly from any of the web applications. <code>*</code></li>
  </ul>
  
  <p>These are all <strong>immutable</strong> requirements as far as I'm concerned - I have to make SSO work without violating any of the above constraints.</p>
  
  <p>Given all that, I don't think I can implement a typical SSO setup, as that would require me to be able to go <code>SP -&gt; IdP -&gt; SP</code>, but I will not be able to perform the <code>SP -&gt; IdP</code> step - I will only be able to perform the <code>IdP -&gt; SP</code> step.</p>
  
  <p>Now, there are solutions here. I have seen <code>mod_mellon</code>, <code>mod_auth_saml</code>, and <code>mod_shib</code>, which all support SAML in Apache, and I know that at least <code>mod_mellon</code> will pass through the results of the SAML authentication in the headers of the HTTP request. So that does basically solve my problem, but for a couple of things I will get to in a minute.</p>
  
  <p>What I would ultimately like is something similar to this, except that Apache would perform the authentication and send through the results of that authentication through to the web apps.</p>
  
  <p>Thus, the flow would be something like:</p>
  
  <p><code>Request -&gt; Not Authenticated -&gt; Redirect to Login Page -&gt; Authenticate (e.g. via LDAP) -&gt; Add results to headers -&gt; Redirect to requested page</code>, all without leaving Apache.</p>
  
  <p>This is exactly the same flow as a typical SSO provider, except that Apache is essentially acting as both the IdP and a Reverse Proxy, and it informs the SP that Authentication was successful by including the results in the headers. It might be <em>simpler</em> to go with a separate IdP, but I'd like to avoid the overhead if I possibly can.</p>
  
  <p>Finally, regardless of whether I go with Apache <em>plus</em> IdP, or Apache <em>as</em> IdP, I'd need to be able to secure what's being added to the headers, e.g. by signing them.</p>
  
  <p>Hang on a second, though - if I want to sign these things, maybe I should just include a SAML token, since the SAML standard (and libraries) takes care of that...</p>
  
  <p>Last question, then: <strike>Is it possible to have Apache act as an SP, make the call to an IdP, then forward the SAML token on to the App that's behind the reverse proxy?</strike> Upon further reading, it appears that the <code>ECP</code>, or "Enhanced Client or Proxy Profile" might allow for this. It's not intended for this use case (it's actually intended for, e.g. a WAP proxy), but it might allow me to do what I want. <strike>Does the SAML standard allow for something other than the SP to initiate the login request?</strike> It does, and is called <code>IdP-Initiated SSO</code>. <strike>I believe the first part of this question is still relevant, however.</strike></p>
  
  <p>I'd really appreciate any suggestions or comments anyone has (even "WTF are you trying to do?!" comments are appreciated).</p>
  
  <p><code>*</code> I should note that while in this situation, we have control over all the pieces of the puzzle, there are likely to be situations where we are required to, for security-related reasons, allow a clients' users to login to our application via their SSO infrastructure, but where we do not have network access to their IdP. Their IdP would, however, have network access to our reverse proxy. I believe that this was actual requirement for a recent potential client.</p>