Form and SSO authentication

[Ashwini Jadhav]

We are migrating our application from JBoss EAP 6.4 to Wildfly18. Currently application is using "org.jboss.as.web.security.ExtendedFormAuthenticator" valve and "org.apache.catalina.authenticator.SingleSignOn".

But since valves are not supported in Wildfly 18, those shall be replaced with authentication mechanism. Is any built in mechanism avaliable for these valves and how to use that?  

[Paul Ferraro]

See https://docs.wildfly.org/18/WildFly_Elytron_Security.html#Web_Single_Sign_On

And post any follow-up question here.

[Ashwini Jadhav]

Thanks for quick reply Paul.

I will refer provided link for SSO. But need more details on below point.

1. Our application is a legacy app and it is storing credentials in oracle app. What about j_exception, in 6.4 it was there, now it is not there in undertow, how it is handled? 

2. How about replacement for "org.jboss.as.web.security.ExtendedFormAuthenticator" valve. Do we need a replacement for this valve or undertow takes care of this?

Regards,

Ashwini Jadhav.

[Ashwini Jadhav]

Regarding SSO, https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/migration_guide/server_configuration_changes#migrate_single_sign_on_server_changes mentions in section 4.14. Single Sign-on Server Changes, as below.

In JBoss EAP 7, SSO is configured in the undertow subsystem of the server configuration file.

There are no application code changes required for SSO when migrating to JBoss EAP 7.

What does this means?

[Paul Ferraro]

EAP 7.0 is based on WF 10.1.  Don't use that documentation as a guide for WF18.

[Ashwini Jadhav]

How about the replacement for "org.jboss.as.web.security.ExtendedFormAuthenticator" valve in WF18. Is there built in authentication mechanism in undertow that automatically takes care of it? Can you please provide more details on this. Migration guides mentions about the custom authentication mechanism shall be implemented for custom valve, also default handlers are provided for some of the valves but details are not present on authentication valve migration in WF18.

--
You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/G699fqPdJkI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/0445e792-92d5-4599-8fc6-07a5dd995e88n%40googlegroups.com.

[Darran Lofthouse]

Here is a blog post I wrote a while back regarding implementing a custom HTTP authentication mechanism:

https://darranl.blogspot.com/2018/02/wildfly-elytron-implementing-custom.html

It is also worth noting WildFly makes the Jakarta EE security specification available which provides an option for deployments using CDI to provide their own authentication mechanism.

For a third option we also still support the JASPI specification as Jakarta EE security it built on top of this, JASPI provides a slightly lower level option for providing a mechanism.

[Ashwini Jadhav]

Custom authentication mechanisam is required for custom valves. That is understood. But is there any equivalent in built mechanism present for third party valve used org.jboss.as.web.security.ExtendedFormAuthenticator.

Also what about j_exception? In 6.4 it was there but now it is not present in undertow. How to handle this?

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d621726e-ec3c-4ec0-81b8-115266b08357n%40googlegroups.com.

[Darran Lofthouse]

No there is no equivalent to ExtendedFormAuthenticator. For something based on FORM authentication I would suggest starting by looking at our implementation first which is available here:

https://github.com/wildfly-security/wildfly-elytron/tree/1.x/http/form

TBH it is so long now since I worked on authentication with Tomcat / JBoss Web - what is j_exception providing for you at the moment?

[Ashwini Jadhav]

What does ExtendedFormAuthenticator do exactly? It puts j_username, j_password and j_exception in session. Is this the only purpose of ExtendedFormAuthenticator? 

What happens if we do not put these in session? Will this have any impact in the cluster environment?

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/df8f89dc-2f88-4b0c-950f-3583e2e23a65n%40googlegroups.com.

[Darran Lofthouse]

Do you make use of any of these values stored in the session from that valve?  We don't.

[Ashwini Jadhav]

Yes, we use j_username and j_exception stored in the session using ExtendedFormAuthenticator valve.

[Darran Lofthouse]

There will be no equivalent for j_exception TBH I don't know what that one does.

But for j_username an application can always obtain the current authenticated identity / caller principal to identify the name of the caller.