[undertow-dev] AuthenticationMechanismFactory

[Stuart Douglas]

There already is one:

io.undertow.servlet.api.DeploymentInfo#setJaspiAuthenticationMechanism

At the moment it is used for JASPI only, hence the name. I thought about giving it a more generic sounding name but in general I don't really want to encourage its use, unless it is actually needed.  

Why do you need this? 

Stuart

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 13 December, 2013 12:23:22 AM
> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> 
> Stuart,
>    would it be possible to have an overloaded method in the
> DeploymentInfo (as before) to just add one authentication mechanism
> without the factory?  You can have the other addAuthenticationMechanism
> method to do your factory you are describing here.
> 
> Regards,
> Anil
> 
> On 12/12/2013 05:14 PM, Stuart Douglas wrote:
> > 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
> > file.
> >
> > 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 intent.
> >
> > The fact that not all methods may use the form data parser is irrelevant,
> > some methods will and so it is provided.
> >
> > Stuart
> >
> >
> >
> > ----- Original Message -----
> >> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >> To: undertow-dev at lists.jboss.org
> >> Sent: Thursday, 12 December, 2013 11:10:48 PM
> >> Subject: [undertow-dev] AuthenticationMechanismFactory
> >>
> >> Stuart,
> >>     I am trying to understand the reasoning behind the new factory added
> >> for authentication mechanisms
> >> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/security/api/AuthenticationMechanismFactory.java
> >>
> >> 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.
> >>
> >> Regards,
> >> Anil
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>