ExternalAuth

[Cantor, Scott]

On 12/23/13, 8:44 PM, "Nick Amon" <namon at xceedium.com> wrote:

> 
>Thanks for the response.  Fortunately, in this case the external
>authentication engine is running on the same system as the IdP.

That doesn't matter. It's not in Java, therefore it's not the same system
and you will be implementing a SSO protocol or you will have an unsafe
system.

>  As you cited, our web app
> is running in apache that is bridged to a tomcat server via AJP running
>the IdP.  Unfortunately though, our authentication engine is implemented
>in PHP and therefore we cannot use the
>AuthenticationEngine->returnToAuthenticationEngine nor can we redirect
>the user back to the AuthenticationEngine servlet with the principal_name
>as part of the query string.  It appears the AuthenticationEngine expects
>these values to be set via the setAttribute method of the
>HttpServletRequest class.

Yes, because that means it's secure insofar as the touchpoint with the
IdP. If you have to do additional work, then that work by definition
becomes a new SSO protocol that you are solely responsible for. We have no
involvement and take no responsibility for any vulnerabilities you
introduce. You should only use that handler if you are experienced in the
design and implementation of SSO protocols. It's basically a lot of rope
to hang yourself with.

> 
>The next approach I am going to take is proxying communcation to our
>external authentication engine via servlet running in the container.  The
>Idp will forward external authentication requests to this servlet, which
>will convert the request attributes to a query string and forward the
>request to our PHP authentication engine.

That sounds unsafe, but without knowing details (and I'm not going to
review them), it's impossible to say. A true proxy that prevents any
access by a client, and a system where those parameters are server side,
and never exposed to a client, might work.

>  Our authentication engine on completion will return the result back to
>the servlet, which
> will set the results as attributes on the HttpServletReqest, then
>complete the authentication by invoking AuthenticationEngine->
>returnToAuthenticationEngine.   Is this the correct approach conforming
>to the intended usage of the ExternalAuthentication handler?

The intended approach is that people who can design their own protocols
are able to integrate them using a Java servlet. That's all we "own" in
terms of the process.

-- Scott