Elytron: FORM and BASIC Authentication in the same Application

[raytucson]

I have an application that we are moving off of WebSphere and considering Wildfly/JBoss.  The application requires that human data entry be secured through FORM authentication (j_security_check), and, it requires that machines can enter data, via a REST API, using BASIC.  It seems that the legacy security system around JAAS has a hard time with these requirements.

I did find this thread, but was still unclear. wildfly Elytron Security-Domain with multiple Security-Realm

In other words, I have one application that needs multiple authentication and authorization mechanisms depending on if the client is a human or a machine.  Can Elytron support these requirements?  My team is willing to learn about Elytron, but first I need to do my due diligence and determine if a Wildfly platform is capable in the first place.  Also, a basic high level solution design would also be appreciated.  Maybe JASPIC instead?

Thanks in Advance, Ray

[dlofthouse]

Elytron has been developed to support multiple authentication mechanisms concurrently - but I am just thinking there may be one issue with the scenario you describe.

As an example we support SPNGEO authentication and FORM authentication concurrently, this works because if the browser can not handle the SPNEGO challenge it will display the login page instead so effectively giving the user a silent fallback.

In your scenario however the browser would understand the challenge for BASIC and attempt to present that to the user before the login page.  I could definitely however look at adding a configuration option to our BASIC mechanism to make it silent so it can handle incoming BASIC headers without sending it's own challenge.

[dlofthouse]

[ELY-1466] Add configuration option to BASIC mechanism to switch off challenging - JBoss Issue Tracker

[mchoma]

Is defining different url for rest api option for you? Thus you could configure different authentication mechanism for different url in web.xml.

[raytucson]

Hi Martin,

Thanks for you reply.

Definitely, different relative paths.  For clarity, the IP address, port, and application name must be the same because it is the same application.  Eg.

http://9.8.7.6:80/AppName/web/personSubmit.html
http://9.8.7.6:80/AppName/rest/personSubmit

What would Elytron configuration for this look like, at a high level?

[mchoma]

My idea is to define multiple security constraints for different url-patterns in web.xml. One security constraint for FORM and second for BASIC authentication.

Elytron http authentication factory will be configured to handle both FORM and BASIC.

However I am not sure if this should work, I haven't tried it myself. dlofthouse, what do you think?

[dlofthouse]

The problem with that approach is the authentication methods apply to the complete web application so although different roles can be defined for different paths they still share a common auth method.

[mchoma]

You are right. I haven't realized that.

[melloware]

Ray,

We have this same requirement and in Jboss EAP 6 we wrote our own "MutliAuthValve" that looked like this in jboss-web.xml.

    <valve>

        <class-name>com.melloware.valve.MultiAuthValve</class-name>

        <param>      

            <param-name>basicAuthUrl</param-name>

            <param-value>/rest/secure/</param-value>

        </param>

    </valve>

Where it was FORM based auth for all URLs but BASIC auth for the URL listed in the Valve in this case everything under "/rest/secure" would be BASIC auth.  Now in Jboss EAP 7 Catalina Valve's have gone away in favor of Elytron "handlers".  I am hoping we can do something similar for Wildfly Elytron and create a MultiAuthHandler.

Attached in the code for the MutliAuthValue it may help you for Wildfly to do the same thing!  Maybe between us we can extend FormAuthenticator in Elytron like this Valve extends Catalina's FormAuthenticator.

Thoughts anyone?

[melloware]

Wow I just found this in the docs.

http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#servlet-security

Securing a Servlet Deployment

Undertow provides full support for all security constructs specified in the Servlet specification. These are configured via the DeploymentInfo structure, and in general closely mirror the corresponding structures as defined by annotations or web.xml. These structures are not detailed fully here, but are covered by the relevant javadoc.

If you are using Wildfly then then it is possible to configure multiple mechanisms using web.xml, by listing the mechanism names separated by commas. It is also possible to set mechanism properties using a query string like syntax.

For example:

<auth-method>BASIC?silent=true,FORM</auth-method>

The mechanisms will be tried in the order that they are listed. In the example silent basic auth will be tried first, which is basic auth that only takes effect if an Authorization header is present. If no such header is present then form auth will be used instead. This will allow programatic clients to use basic auth, while users connecting via a browser can use form based auth.

[mchoma]

But I think this is valid for non-Elytron (legacy) solution.

In Elytron similar needs to be implemented [1].

[1] [ELY-1466] Add configuration option to BASIC mechanism to switch off challenging - JBoss Issue Tracker