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.
Is defining different url for rest api option for you? Thus you could configure different authentication mechanism for different url in web.xml.
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.
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?
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.
You are right. I haven't realized that.
We have this same requirement and in Jboss EAP 6 we wrote our own "MutliAuthValve" that looked like this in jboss-web.xml.
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.
MultiAuthValve.java 5.8 KB
Wow I just found this in the docs.
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.
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
Authorizationheader 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.
But I think this is valid for non-Elytron (legacy) solution.
In Elytron similar needs to be implemented .