There are a few major advantages.
Now all an extension does is register the factory, and the user can enable it in web.xml
(or jboss-web.xml) using whatever options they want, in whatever order they want. If an
extension really wants to completely override the auth mechanism it can still do that, by
simply clearing the auth mechanism list and adding the name of its mechanism instead.
Basically before there was no real way for extensions to play nicely with each other.
Undertow has the ability for multiple authentication mechanisms to work correctly
together, but with the old way there was no reliable way to actually use this with custom
authentication mechanisms, as there was no way to specify order.Custom mechanisms would
also need to have a custom way of configuration, e.g. reading options from a separate
Now custom mechanisms work exactly the same way as the standard mechanisms, it is easy to
specify the order, it is easy to configure any properties that may be required, and no
functionality has been lost, as an extension can still override auth mechanisms if that is
The fact that not all methods may use the form data parser is irrelevant, some methods
will and so it is provided.
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
Sent: Thursday, 12 December, 2013 11:10:48 PM
Subject: [undertow-dev] AuthenticationMechanismFactory
I am trying to understand the reasoning behind the new factory added
for authentication mechanisms
Why not just allow the direct install of authentication mechanisms like
we did before in the DeploymentInfo?
I am unsure we need another level of indirection with this factory which
also has access to the FormDataParser. Basically, the specifics of FORM
authentication have sneaked into this factory. Many of the
authentication mechanisms do not even involve forms.
undertow-dev mailing list