ExternalAuth

[Nick Amon]

Thanks Scott for your response.  I will  document the design that I am goinging forward with hoping that any of you experts out there can spot any apparent vulnerabilities.

Setup:
---------
Idp running in tomcat
PHP authentication engine running in apache
Both are running on the same host

PHP authentication engine after successfully authenticating a user, sets the PHP session ID cookie for the domain and also writes the session ID in a local database accessible only to the Idp and PHP AuthEngine.

Idp ExternalAuth is configured to forward authentication requests to a servlet running in the same proxy.   This servlet, subsequently referred to as the PHPAuthEngineServletProxy, on receipt of a auth request from AuthEngine, checks if there is an existing PHP session ID cookie and if so, verifies that it is in the local database. If it is in the local database, it considers the user authenticated and returns the user back to AuthEngine.

If there is no session ID cookie, or the session is not found in the local database, the PHPAuthEngineServletProxy redirects the user to the PHP AuthEngine for authentication.  After the PHPAuthEngine has successfully authenticated the user and set the PHP session ID cookie, it redirects the user back to the PHPAuthEngineServletProxy, which verifies that session ID cookie against the database and forwards control back to the AuthEngine.

I have implemented this and seems to function fairly well.  I don't see any apparent vulnerabilities in this design.

Thanks,

Nicholas

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, December 24, 2013 1:25 PM
To: Shib Users
Subject: Re: ExternalAuth

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


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