ExternalAuth

[Nick Amon]

Nate,

Thanks for the response.  Fortunately, in this case the external authentication engine is running on the same system as the IdP.  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.

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.  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?

Thanks,

Nicholas

From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Nate Klingenstein
Sent: Monday, December 23, 2013 8:15 PM
To: Shib Users
Subject: Re: ExternalAuth

Nick,

I can't answer this one for certain but I believe ExternalAuth implies that the external authentication system has to be part of the same web environment as the IdP rather than requiring that it run in the same container(e.g. Apache -> AJP -> Tomcat, with the authentication mechanism sitting in Apache).  This is true of at least REMOTE_USER based login.

Anything that involves one system making authentication queries out to an entirely separate system is basically building a custom SSO protocol with all the security that must come with it.  That can be done, of course, but it's easy to make implementation mistakes that become security vulnerabilities, and it's not something that Extternal Auth was trying to achieve with its much simpler set of parameters.

Hope I got it right,
Nate.

On Dec 23, 2013, at 4:02 PM, Nick Amon <namon at xceedium.com<mailto:namon at xceedium.com>>
 wrote:


I would like to integrate Shibboleth 2.4 with the authentication engine of our existing application.  I have determined from the documentation that this is doable with the ExternalAuthn LoginHandler but it appears that the external authentication system must  be Java based (i.e. a servlet) and that it is running in the same container.  Our authentication engine is running in Apache has a PHP application.  Would I still be able to use the ExternAuthn handler to forward authentication requests to it?  How would I return control pack to the AuthEngine, by redirecting the user back to the AuthEngine URL along w/ the required authentication result parameters?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131224/2b611cef/attachment.html