integrating service with existing identity provider?
Cantor, Scott
cantor.2 at osu.edu
Fri Oct 12 20:27:18 EDT 2012
On 10/12/12 7:45 PM, "Brendan Miller" <catphive at catphive.net> wrote:
>So, what I'm having a hard time understanding is how authentication
>information is communicated to node. Node is its own web server. It
>doesn't live within apache or any other server, though it can exist
>behind a proxy. I think the same is more or less true with tomcat.
Tomcat does not require HTTP proxying to use with Apache. The AJP protocol
tunnels HTTP in binary fashion in a special way into the Tomcat layer,
which is more efficient and more generally reliable in terms of making the
application appear to be "inside" Apache.
Most other servers that support Apache as a front-end tend to use HTTP
proxying, which is more limited in terms of the integration. For example,
AJP allows REMOTE_USER from Apache to be tunneled over, but HTTP proxying
does not.
The SP is native code, therefore it does not run inside servers like
Tomcat or Node. Web servers with sufficient C extension APIs can be
programmed to support the SP, but the only ones I have done so with are
the ones supported.
>Can shiboleth SP act as a proxy and communicate authentication
>information via inserting custom headers or something like that?
Yes, that's one way of front-ending non-commodity web servers with it.
That doesn't make it a good choice for everybody, but if having a best of
breed SAML implememtation is more important than not using Apache, it is
sometimes a worthwhile trade-off.
> I get the impression that's what you guys do for IIS, but I wasn't clear
>on
>whether that only works with IIS or works with a generic web server.
I support IIS because I wrote the IIS filter and extension to run inside
IIS. The header mwchanism is how the filter communicates to the
*applications* behind IIS, if that's what you mean, but that isn't how the
IIS support itself is done (via front-ending I mean).
>I don't think node supports fastCGI.
I doubt it, but I haven't looked.
-- Scott
More information about the dev
mailing list