From sdouglas at redhat.com  Mon Dec  2 04:28:58 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 2 Dec 2013 04:28:58 -0500 (EST)
Subject: [undertow-dev] Authentication Mechanism Configuration
In-Reply-To: <1166527039.29716267.1385581940032.JavaMail.root@redhat.com>
References: <5293628B.9000208@jboss.com>
	<1510731691.28630317.1385411201026.JavaMail.root@redhat.com>
	<5293B862.4010908@redhat.com>
	<1462370554.29615407.1385568347437.JavaMail.root@redhat.com>
	<52962679.4020403@jboss.com>
	<1483746243.29665691.1385573646088.JavaMail.root@redhat.com>
	<52962E25.8030407@jboss.com>
	<1166527039.29716267.1385581940032.JavaMail.root@redhat.com>
Message-ID: <1135402345.30667260.1385976538153.JavaMail.root@redhat.com>

So I have gone ahead with this. 

Basically DeploymentInfo now contains a map of name -> AuthenticationMechanismFactory, and the LoginConfig class now has a list of AuthMethodConfig
structures, which are basically just a name and a properties map. 

Wildfly will be setup to parse comma separate auth methods with properties specified via a query string like syntax, e.g.:

BASIC?silent=true,FORM?error_page=error/page/override.html&post_location=/custom_location

So basically something like oauth can simply register a factory under the name OAUTH (or maybe com.keycloak.OAUTH to prevent clashes), and then rely on the user specifying that they want to use it in web.xml. 

If you want to register additional handlers etc then your extension should simply iterate over the auth mechanisms list, and if your mechanisms name is mentioned then then install your handlers. If you want to completely ignore what is in web.xml you can just clear the auth methods list and add your own method.  

As a result of this I have got rid of the additional authentication mechanims list, and the ignore standard methods flag, as they should not longer be nessesary. Unfortunately this is causing problems for the JASPI integration, so I am probably going to add a special hook for JASPI. 

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Wednesday, 27 November, 2013 8:52:20 PM
> Subject: Re: [undertow-dev] Authentication Mechanism Configuration
> 
> Yes, that was another reason why I think the extensions should just register
> a name, otherwise ordering between mechanisms would just be a mess.
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
> > To: "Stuart Douglas" <sdouglas at redhat.com>, "Darran Lofthouse"
> > <darran.lofthouse at jboss.com>
> > Cc: "Bill Burke" <bburke at redhat.com>, undertow-dev at lists.jboss.org
> > Sent: Wednesday, 27 November, 2013 6:38:45 PM
> > Subject: Re: [undertow-dev] Authentication Mechanism Configuration
> > 
> > On 27/11/13 17:34, Stuart Douglas wrote:
> > >>
> > >> One feature within JBoss Web was that at deployment time if an
> > >> authentication mechansism is already set on a web app the default
> > >> mechanism handling was skipped - we may also want to consider this to
> > >> allow deployers within WildFly to take over this handling.
> > >
> > > Not sure exactly what you mean here, an extension can remove other
> > > mechanisms if it desires.
> > 
> > What I mean here is making sure we don't have mechanisms being added
> > from multiple locations - but maybe if the deployers are just setting
> > names and factories and Undertow calls the factories that double
> > processing of methods would not occur.
> > 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From Anil.Saldhana at redhat.com  Tue Dec  3 16:03:27 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 03 Dec 2013 15:03:27 -0600
Subject: [undertow-dev] Form Authentication : Save/Restore Request
Message-ID: <529E471F.4040308@redhat.com>

Hi,
   looking at the FormAuthenticationMechanism code, I cannot figure out 
whether the original request gets cached (saved) before redirecting to 
the form login page. After authentication, it needs to be restored back. 
This is the only way in which the original post data to a secured URL 
can be saved after the form authentication work flow.

Regards,
Anil

From Anil.Saldhana at redhat.com  Tue Dec  3 16:06:21 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 03 Dec 2013 15:06:21 -0600
Subject: [undertow-dev] Form Authentication : Save/Restore Request
In-Reply-To: <529E471F.4040308@redhat.com>
References: <529E471F.4040308@redhat.com>
Message-ID: <529E47CD.6080009@redhat.com>

Sometime ago, I did write the form auth code in a generic library
https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/HTTPFormAuthentication.java
https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/AbstractHTTPAuthentication.java

This does request caching.

On 12/03/2013 03:03 PM, Anil Saldhana wrote:
> Hi,
>     looking at the FormAuthenticationMechanism code, I cannot figure out
> whether the original request gets cached (saved) before redirecting to
> the form login page. After authentication, it needs to be restored back.
> This is the only way in which the original post data to a secured URL
> can be saved after the form authentication work flow.
>
> Regards,
> Anil
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From samy at dindane.com  Sun Dec  8 12:09:23 2013
From: samy at dindane.com (Samy Dindane)
Date: Sun, 8 Dec 2013 18:09:23 +0100
Subject: [undertow-dev] Force a HttpHandler to accept POST only
Message-ID: <etPan.52a4a7c3.19495cff.4aac@silenthour>

Hi folks,?

I have a?HttpHandler that I want to reach with POST requests?only.?
I tried?exchange.setRequestMethod(new HttpString("POST?))?inside handleRequest(), but the HttpHandler still responds to?GET?requests.?

Is there any way to do this??

In case you?d like to check out the code, it can be found?here.?
Thank you.?

Samy?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131208/38e434fd/attachment.html 

From samy at dindane.com  Sun Dec  8 12:27:54 2013
From: samy at dindane.com (Samy Dindane)
Date: Sun, 8 Dec 2013 18:27:54 +0100
Subject: [undertow-dev] Consider a PathHandler's URL as the full one,
	not as a prefix
Message-ID: <etPan.52a4ac1b.625558ec.4aac@silenthour>

Hello,?

When a URL is passed to PathHandler#addPath(String url, ?), it is considered as a URL prefix. Which means one can set the URL to ?/foo? and can reach ?/foo/bar? too.?

Is there any way to avoid this??
Thanks.?

Samy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131208/414b2d63/attachment.html 

From sdouglas at redhat.com  Mon Dec  9 04:21:15 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 04:21:15 -0500 (EST)
Subject: [undertow-dev] Form Authentication : Save/Restore Request
In-Reply-To: <529E47CD.6080009@redhat.com>
References: <529E471F.4040308@redhat.com> <529E47CD.6080009@redhat.com>
Message-ID: <1251685034.33998045.1386580875542.JavaMail.root@redhat.com>

This still needs to be implemented: https://issues.jboss.org/browse/UNDERTOW-156

I should get to it some time this week.

Stuart

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Tuesday, 3 December, 2013 10:06:21 PM
> Subject: Re: [undertow-dev] Form Authentication : Save/Restore Request
> 
> Sometime ago, I did write the form auth code in a generic library
> https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/HTTPFormAuthentication.java
> https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/AbstractHTTPAuthentication.java
> 
> This does request caching.
> 
> On 12/03/2013 03:03 PM, Anil Saldhana wrote:
> > Hi,
> >     looking at the FormAuthenticationMechanism code, I cannot figure out
> > whether the original request gets cached (saved) before redirecting to
> > the form login page. After authentication, it needs to be restored back.
> > This is the only way in which the original post data to a secured URL
> > can be saved after the form authentication work flow.
> >
> > Regards,
> > Anil
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From sdouglas at redhat.com  Mon Dec  9 05:10:39 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 05:10:39 -0500 (EST)
Subject: [undertow-dev] Force a HttpHandler to accept POST only
In-Reply-To: <etPan.52a4a7c3.19495cff.4aac@silenthour>
References: <etPan.52a4a7c3.19495cff.4aac@silenthour>
Message-ID: <2083228356.34008108.1386583839902.JavaMail.root@redhat.com>

What do you want to happen if it is not a post request?

The simplest way is just:

if(!exchange.getRequestMethod().equals(Methods.POST)) {
  exchange.setResponseCode(405);
  exchange.endExchange();
  return;
}

If you want to pick a handler to invoke based on the method you can use:

Handlers.predicate(Predicates.method(Methods.POST), postHandler, nonPostHandler);

Stuart

----- Original Message -----
> From: "Samy Dindane" <samy at dindane.com>
> To: undertow-dev at lists.jboss.org
> Sent: Sunday, 8 December, 2013 6:09:23 PM
> Subject: [undertow-dev] Force a HttpHandler to accept POST only
> 
> Hi folks,
> 
> I have a HttpHandler that I want to reach with POST requests only .
> I tried exchange.setRequestMethod(new HttpString("POST?)) inside
> handleRequest() , but the HttpHandler still responds to GET requests.
> 
> Is there any way to do this?
> 
> In case you?d like to check out the code, it can be found here .
> Thank you.
> 
> Samy
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Mon Dec  9 05:35:12 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 05:35:12 -0500 (EST)
Subject: [undertow-dev] Consider a PathHandler's URL as the full one,
	not as a prefix
In-Reply-To: <etPan.52a4ac1b.625558ec.4aac@silenthour>
References: <etPan.52a4ac1b.625558ec.4aac@silenthour>
Message-ID: <2124776843.34012039.1386585312209.JavaMail.root@redhat.com>


> Hello,
> 
> When a URL is passed to PathHandler#addPath(String url, ?) , it is considered
> as a URL prefix. Which means one can set the URL to ?/foo? and can reach
> ?/foo/bar? too.

I just implemented this in Undertow upstream, it should be available in the next release. 

Basically instead of addPath you now have addPrefixPath and addExactPath, with addPath now being a deprecated version of addPrefixPath.

I also added another path handler called PathTemplateHandler, that matches based on RFC 6570 level one URI templates, so you can do things like:

addPath("/setting/{username}/account")


Stuart



> 
> Is there any way to avoid this?
> Thanks.
> 
> Samy
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From samy at dindane.com  Mon Dec  9 08:27:19 2013
From: samy at dindane.com (Samy Dindane)
Date: Mon, 9 Dec 2013 14:27:19 +0100
Subject: [undertow-dev] Force a HttpHandler to accept POST only
In-Reply-To: <2083228356.34008108.1386583839902.JavaMail.root@redhat.com>
References: <etPan.52a4a7c3.19495cff.4aac@silenthour>
	<2083228356.34008108.1386583839902.JavaMail.root@redhat.com>
	<2083228356.34008108.1386583839902.JavaMail.root@redhat.com>
Message-ID: <etPan.52a5c538.12200854.4aac@silenthour>

On 9 d?cembre 2013 at 11:10:49, Stuart Douglas (sdouglas at redhat.com) wrote:
What do you want to happen if it is not a post request??

I was thinking about a 404 error, but indeed, 405 is more relevant.?

The simplest way is just:?

if(!exchange.getRequestMethod().equals(Methods.POST)) {?
exchange.setResponseCode(405);?
exchange.endExchange();?
return;?
}?
This way suits me, thank you.?

How can I retrieve the POST parameters ? I only can access the GET ones with?getQueryParameters().

If you want to pick a handler to invoke based on the method you can use:?

Handlers.predicate(Predicates.method(Methods.POST), postHandler, nonPostHandler);?
Do you think it?s a good idea to create a handler for any 404 error page and use it here ??

If so, is it possible to set it as the default handler for all 404 errors ? (I can do the check manually but I?m wondering if it is supported by default)?



Stuart?

----- Original Message -----?
> From: "Samy Dindane" <samy at dindane.com>?
> To: undertow-dev at lists.jboss.org?
> Sent: Sunday, 8 December, 2013 6:09:23 PM?
> Subject: [undertow-dev] Force a HttpHandler to accept POST only?
>?
> Hi folks,?
>?
> I have a HttpHandler that I want to reach with POST requests only .?
> I tried exchange.setRequestMethod(new HttpString("POST?)) inside?
> handleRequest() , but the HttpHandler still responds to GET requests.?
>?
> Is there any way to do this??
>?
> In case you?d like to check out the code, it can be found here .?
> Thank you.?
>?
> Samy?
>?
> _______________________________________________?
> undertow-dev mailing list?
> undertow-dev at lists.jboss.org?
> https://lists.jboss.org/mailman/listinfo/undertow-dev?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131209/2da108a7/attachment-0001.html 

From sdouglas at redhat.com  Mon Dec  9 08:44:27 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 08:44:27 -0500 (EST)
Subject: [undertow-dev] Force a HttpHandler to accept POST only
In-Reply-To: <etPan.52a5c538.12200854.4aac@silenthour>
References: <etPan.52a4a7c3.19495cff.4aac@silenthour>
	<2083228356.34008108.1386583839902.JavaMail.root@redhat.com>
	<2083228356.34008108.1386583839902.JavaMail.root@redhat.com>
	<etPan.52a5c538.12200854.4aac@silenthour>
Message-ID: <759019257.34067671.1386596667062.JavaMail.root@redhat.com>


> 
> On 9 d?cembre 2013 at 11:10:49, Stuart Douglas (sdouglas at redhat.com) wrote:
> What do you want to happen if it is not a post request?
> 
> I was thinking about a 404 error, but indeed, 405 is more relevant.
> 
> The simplest way is just:
> 
> if(!exchange.getRequestMethod().equals(Methods.POST)) {
> exchange.setResponseCode(405);
> exchange.endExchange();
> return;
> }
> This way suits me, thank you.
> 
> How can I retrieve the POST parameters ? I only can access the GET ones with
> ?getQueryParameters().

For now you need to use io.undertow.server.handlers.form.FormDataParser (see io.undertow.server.handlers.form.FormDataParserTestCase for an example).

I am not super happy with this API so it will probably change soon.

> 
> If you want to pick a handler to invoke based on the method you can use:
> 
> Handlers.predicate(Predicates.method(Methods.POST), postHandler,
> nonPostHandler);
> Do you think it?s a good idea to create a handler for any 404 error page and
> use it here ?
> 
> If so, is it possible to set it as the default handler for all 404 errors ?
> (I can do the check manually but I?m wondering if it is supported by
> default)


io.undertow.server.handlers.ResponseCodeHandler#HANDLE_404

This is a handler that sets a 404 response code and ends. 

If you want to generate a default error page for 404 responses have a look at io.undertow.server.handlers.error.SimpleErrorPageHandler for an example of how to do this. 

Stuart


> 
> 
> 
> Stuart
> 
> ----- Original Message -----
> > From: "Samy Dindane" <samy at dindane.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Sunday, 8 December, 2013 6:09:23 PM
> > Subject: [undertow-dev] Force a HttpHandler to accept POST only
> >?
> > Hi folks,
> >?
> > I have a HttpHandler that I want to reach with POST requests only .
> > I tried exchange.setRequestMethod(new HttpString("POST?)) inside
> > handleRequest() , but the HttpHandler still responds to GET requests.
> >?
> > Is there any way to do this?
> >?
> > In case you?d like to check out the code, it can be found here .
> > Thank you.
> >?
> > Samy
> >?
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>


From bburke at redhat.com  Mon Dec  9 08:55:52 2013
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Dec 2013 08:55:52 -0500
Subject: [undertow-dev] Security, DeploymentInfo SPIs settled?
Message-ID: <52A5CBE8.3040605@redhat.com>

Are the security and DeploymentIno SPIs settled now?  Is Wildfly in sync 
too?  Want to finish up my security adapter.

Thanks.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From lanabe.lanabe at gmail.com  Mon Dec  9 09:13:05 2013
From: lanabe.lanabe at gmail.com (lanabe)
Date: Mon, 9 Dec 2013 23:13:05 +0900
Subject: [undertow-dev] About response time in access log
Message-ID: <CAKhWDPTF38FvLmfs=hH=RuqaivJh_6+Qd4HUnMRd9WJv=m3sMA@mail.gmail.com>

Hi, everyone.

Now Undertow AccessLogHandler is not supported Response time(%D/%T), right?

I simply implemented it, but I'm not sure..

https://github.com/emag/undertow/commit/6401d61e3fcb5ce739ce4f30ae0d6fb3ad68cc37

My code is

1) Add startTime:long field in HttpServerExchange
2) Initialize startTime and assign System.currentTimeMillis to it in
HttpServerExchange#<init>
3) Create ResponseTimeAttribute and its readAttribute return
(System.currentTimeMillis - exchage.getStartTime)

Is it too simple?

-----
I checked handler chain stack trace on WildFly Beta1.

(default I/O-3)
io.undertow.server.handlers.resource.ResourceHandler.handleRequest(ResourceHandler.java:76)
(default I/O-3)
io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:90)
(default I/O-3)
io.undertow.server.handlers.accesslog.AccessLogHandler.handleRequest(AccessLogHandler.java:93)
[...]

 <Some Handlers> -> AccessLogHandler -> PathHandler -> ResourceHandler

If PathHandler and ResourceHandler(or another process) take a long time, my
idea doesn't work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131209/b8bab1d3/attachment.html 

From sdouglas at redhat.com  Mon Dec  9 09:34:39 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 09:34:39 -0500 (EST)
Subject: [undertow-dev] About response time in access log
In-Reply-To: <CAKhWDPTF38FvLmfs=hH=RuqaivJh_6+Qd4HUnMRd9WJv=m3sMA@mail.gmail.com>
References: <CAKhWDPTF38FvLmfs=hH=RuqaivJh_6+Qd4HUnMRd9WJv=m3sMA@mail.gmail.com>
Message-ID: <543026601.34104204.1386599679698.JavaMail.root@redhat.com>

I think conceptually this is fine, but I would want to do some performance testing before we included this, to make sure that recording the start time for every invocation does not hurt performance (which I suspect it will). 

If this is the case (as I suspect it will be) then we need to basically make it configurable, which is not that hard to do. 

Your statement "If PathHandler and ResourceHandler(or another process) take a long time, my idea doesn't work." is not really correct, the access log handler just registers a completion listener to actually record the values, so the time measurement is not taken until the exchange is complete.

If you create a JIRA about this I will try and find the time to test out performance later this week, and if it is an issue I will add a way to make recoding the request start time configurable. 

Thanks,

Stuart

----- Original Message -----
> From: "lanabe" <lanabe.lanabe at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 9 December, 2013 3:13:05 PM
> Subject: [undertow-dev] About response time in access log
> 
> Hi, everyone.
> 
> Now Undertow AccessLogHandler is not supported Response time(%D/%T), right?
> 
> I simply implemented it, but I'm not sure..
> 
> https://github.com/emag/undertow/commit/6401d61e3fcb5ce739ce4f30ae0d6fb3ad68cc37
> 
> My code is
> 
> 1) Add startTime:long field in HttpServerExchange
> 2) Initialize startTime and assign System.currentTimeMillis to it in
> HttpServerExchange#<init>
> 3) Create ResponseTimeAttribute and its readAttribute return
> (System.currentTimeMillis - exchage.getStartTime)
> 
> Is it too simple?
> 
> -----
> I checked handler chain stack trace on WildFly Beta1.
> (default I/O-3)
> io.undertow.server.handlers.resource.ResourceHandler.handleRequest(ResourceHandler.java:76)
> (default I/O-3)
> io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:90)
> (default I/O-3)
> io.undertow.server.handlers.accesslog.AccessLogHandler.handleRequest(AccessLogHandler.java:93)
> [...]
> 
> <Some Handlers> -> AccessLogHandler -> PathHandler -> ResourceHandler
> 
> If PathHandler and ResourceHandler(or another process) take a long time, my
> idea doesn't work.
> 
> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Mon Dec  9 09:35:46 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 9 Dec 2013 09:35:46 -0500 (EST)
Subject: [undertow-dev] Security, DeploymentInfo SPIs settled?
In-Reply-To: <52A5CBE8.3040605@redhat.com>
References: <52A5CBE8.3040605@redhat.com>
Message-ID: <998847552.34106349.1386599746341.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 9 December, 2013 2:55:52 PM
> Subject: [undertow-dev] Security, DeploymentInfo SPIs settled?
> 
> Are the security and DeploymentIno SPIs settled now?  Is Wildfly in sync
> too?  Want to finish up my security adapter.

Yes, they should be, barring anyone discovering any major problems.

Stuart

> 
> Thanks.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From lanabe.lanabe at gmail.com  Mon Dec  9 10:10:14 2013
From: lanabe.lanabe at gmail.com (lanabe)
Date: Tue, 10 Dec 2013 00:10:14 +0900
Subject: [undertow-dev] About response time in access log
In-Reply-To: <543026601.34104204.1386599679698.JavaMail.root@redhat.com>
References: <CAKhWDPTF38FvLmfs=hH=RuqaivJh_6+Qd4HUnMRd9WJv=m3sMA@mail.gmail.com>
	<543026601.34104204.1386599679698.JavaMail.root@redhat.com>
Message-ID: <CAKhWDPSBSDtz4TJXrEWs5U4=6XusXdW7QmYEhH9RdydaTA2JZw@mail.gmail.com>

Thank you for your reply!

I created the JIRA.

https://issues.jboss.org/browse/UNDERTOW-159


On Mon, Dec 9, 2013 at 11:34 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> I think conceptually this is fine, but I would want to do some performance
> testing before we included this, to make sure that recording the start time
> for every invocation does not hurt performance (which I suspect it will).
>
> If this is the case (as I suspect it will be) then we need to basically
> make it configurable, which is not that hard to do.
>
> Your statement "If PathHandler and ResourceHandler(or another process)
> take a long time, my idea doesn't work." is not really correct, the access
> log handler just registers a completion listener to actually record the
> values, so the time measurement is not taken until the exchange is complete.
>
> If you create a JIRA about this I will try and find the time to test out
> performance later this week, and if it is an issue I will add a way to make
> recoding the request start time configurable.
>
> Thanks,
>
> Stuart
>
> ----- Original Message -----
> > From: "lanabe" <lanabe.lanabe at gmail.com>
> > To: undertow-dev at lists.jboss.org
> > Sent: Monday, 9 December, 2013 3:13:05 PM
> > Subject: [undertow-dev] About response time in access log
> >
> > Hi, everyone.
> >
> > Now Undertow AccessLogHandler is not supported Response time(%D/%T),
> right?
> >
> > I simply implemented it, but I'm not sure..
> >
> >
> https://github.com/emag/undertow/commit/6401d61e3fcb5ce739ce4f30ae0d6fb3ad68cc37
> >
> > My code is
> >
> > 1) Add startTime:long field in HttpServerExchange
> > 2) Initialize startTime and assign System.currentTimeMillis to it in
> > HttpServerExchange#<init>
> > 3) Create ResponseTimeAttribute and its readAttribute return
> > (System.currentTimeMillis - exchage.getStartTime)
> >
> > Is it too simple?
> >
> > -----
> > I checked handler chain stack trace on WildFly Beta1.
> > (default I/O-3)
> >
> io.undertow.server.handlers.resource.ResourceHandler.handleRequest(ResourceHandler.java:76)
> > (default I/O-3)
> >
> io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:90)
> > (default I/O-3)
> >
> io.undertow.server.handlers.accesslog.AccessLogHandler.handleRequest(AccessLogHandler.java:93)
> > [...]
> >
> > <Some Handlers> -> AccessLogHandler -> PathHandler -> ResourceHandler
> >
> > If PathHandler and ResourceHandler(or another process) take a long time,
> my
> > idea doesn't work.
> >
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131210/e348caad/attachment.html 

From Anil.Saldhana at redhat.com  Thu Dec 12 17:10:48 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 12 Dec 2013 16:10:48 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
Message-ID: <52AA3468.9020609@redhat.com>

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

From sdouglas at redhat.com  Thu Dec 12 18:14:28 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 12 Dec 2013 18:14:28 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AA3468.9020609@redhat.com>
References: <52AA3468.9020609@redhat.com>
Message-ID: <666709521.36264491.1386890068982.JavaMail.root@redhat.com>

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
> 

From Anil.Saldhana at redhat.com  Thu Dec 12 18:23:22 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 12 Dec 2013 17:23:22 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <666709521.36264491.1386890068982.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
Message-ID: <52AA456A.3020205@redhat.com>

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

From sdouglas at redhat.com  Fri Dec 13 01:53:00 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 01:53:00 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AA456A.3020205@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
Message-ID: <1403429648.36402703.1386917580592.JavaMail.root@redhat.com>

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
> 

From Anil.Saldhana at redhat.com  Fri Dec 13 02:03:49 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 01:03:49 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
Message-ID: <52AAB155.4010503@redhat.com>

You should remove that setJaspiAuthenticationMechanism and use the 
setAuthenticationMechanism(string,authmech) format. That is my opinion. :)

In my use case, I have a single authentication mechanism which I want to 
use for the webapp
deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);

That is it.

I can use the Factory indirection that you have recently added but it is 
counter intuitive and overkill for my use case.

Users of undertow API will ask the same question or get confused if 
their simple use cases such as mine are not covered with a direct
API method. :)

On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> 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
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Fri Dec 13 02:29:17 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 02:29:17 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AAB155.4010503@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
Message-ID: <1041608808.36407211.1386919757144.JavaMail.root@redhat.com>


> 
> You should remove that setJaspiAuthenticationMechanism and use the
> setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
> 
> In my use case, I have a single authentication mechanism which I want to
> use for the webapp
> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> 
> That is it.
> 
> I can use the Factory indirection that you have recently added but it is
> counter intuitive and overkill for my use case.
> 
> Users of undertow API will ask the same question or get confused if
> their simple use cases such as mine are not covered with a direct
> API method. :)

Why do you want to completely override the method, and ignore whatever method a user has configured? In general I would prefer that mechanisms used the factory mechanism, so they all behave in a consistent manner. What is your use case that makes this not an option?

Stuart

> 
> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> > 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
> >>
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From sdouglas at redhat.com  Fri Dec 13 02:41:21 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 02:41:21 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
Message-ID: <657454061.36408243.1386920481108.JavaMail.root@redhat.com>

For a good example of extensions should just be using the factory mechanism, consider the case for extensions that are bundled with Wildfly. 

If an extension simply tries to take over a deployments authentication mechanism, then we could never bundle it in the server, as it would take over all deployments. Extensions that use the factory mechanism though can be bundled in the server and exposed to all deployments, and the user selects the mechanism to use via a standard descriptor. 

Stuart

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Friday, 13 December, 2013 8:29:17 AM
> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> 
> 
> > 
> > You should remove that setJaspiAuthenticationMechanism and use the
> > setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
> > 
> > In my use case, I have a single authentication mechanism which I want to
> > use for the webapp
> > deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> > 
> > That is it.
> > 
> > I can use the Factory indirection that you have recently added but it is
> > counter intuitive and overkill for my use case.
> > 
> > Users of undertow API will ask the same question or get confused if
> > their simple use cases such as mine are not covered with a direct
> > API method. :)
> 
> Why do you want to completely override the method, and ignore whatever method
> a user has configured? In general I would prefer that mechanisms used the
> factory mechanism, so they all behave in a consistent manner. What is your
> use case that makes this not an option?
> 
> Stuart
> 
> > 
> > On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> > > 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
> > >>
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From darran.lofthouse at jboss.com  Fri Dec 13 05:34:19 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 13 Dec 2013 10:34:19 +0000
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AAB155.4010503@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
Message-ID: <52AAE2AB.80401@jboss.com>

Hi Anil,

For this mechanism can you guarantee to us 100% that there is not going 
to be any demand in the future to combine it with any other mechanism?

Regards,
Darran Lofthouse.


On 13/12/13 07:03, Anil Saldhana wrote:
> You should remove that setJaspiAuthenticationMechanism and use the
> setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
>
> In my use case, I have a single authentication mechanism which I want to
> use for the webapp
> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>
> That is it.
>
> I can use the Factory indirection that you have recently added but it is
> counter intuitive and overkill for my use case.
>
> Users of undertow API will ask the same question or get confused if
> their simple use cases such as mine are not covered with a direct
> API method. :)
>
> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>> 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
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

From bburke at redhat.com  Fri Dec 13 09:27:53 2013
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Dec 2013 09:27:53 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <657454061.36408243.1386920481108.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>	<52AAB155.4010503@redhat.com>	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
Message-ID: <52AB1969.8050905@redhat.com>

This point is bogus.  You can write ServletExtensions that are triggered 
only by metadata defined within a deployment.  I never understood why 
you needed this extra SPI.

Also, at least in my Keycloak case, AuthMechFactory isn't enough for me 
and I have to write an extension anyways.  I need to add additional 
handlers that operate pre and post authentication. 
AuthenticationMechanismFactory is just an additional level of 
indirection I don't want or need.

On 12/13/2013 2:41 AM, Stuart Douglas wrote:
> For a good example of extensions should just be using the factory mechanism, consider the case for extensions that are bundled with Wildfly.
>
> If an extension simply tries to take over a deployments authentication mechanism, then we could never bundle it in the server, as it would take over all deployments. Extensions that use the factory mechanism though can be bundled in the server and exposed to all deployments, and the user selects the mechanism to use via a standard descriptor.
>
> Stuart
>
> ----- Original Message -----
>> From: "Stuart Douglas" <sdouglas at redhat.com>
>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Friday, 13 December, 2013 8:29:17 AM
>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>
>>
>>>
>>> You should remove that setJaspiAuthenticationMechanism and use the
>>> setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
>>>
>>> In my use case, I have a single authentication mechanism which I want to
>>> use for the webapp
>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>
>>> That is it.
>>>
>>> I can use the Factory indirection that you have recently added but it is
>>> counter intuitive and overkill for my use case.
>>>
>>> Users of undertow API will ask the same question or get confused if
>>> their simple use cases such as mine are not covered with a direct
>>> API method. :)
>>
>> Why do you want to completely override the method, and ignore whatever method
>> a user has configured? In general I would prefer that mechanisms used the
>> factory mechanism, so they all behave in a consistent manner. What is your
>> use case that makes this not an option?
>>
>> Stuart
>>
>>>
>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Dec 13 09:58:15 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 09:58:15 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB1969.8050905@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
Message-ID: <2097737379.37028571.1386946695426.JavaMail.root@redhat.com>

Ok, I have added some convenience methods. 

Now you can just do:

d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());

Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.

Stuart

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 13 December, 2013 3:27:53 PM
> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> 
> This point is bogus.  You can write ServletExtensions that are triggered
> only by metadata defined within a deployment.  I never understood why
> you needed this extra SPI.
> 
> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
> and I have to write an extension anyways.  I need to add additional
> handlers that operate pre and post authentication.
> AuthenticationMechanismFactory is just an additional level of
> indirection I don't want or need.
> 
> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
> > For a good example of extensions should just be using the factory
> > mechanism, consider the case for extensions that are bundled with Wildfly.
> >
> > If an extension simply tries to take over a deployments authentication
> > mechanism, then we could never bundle it in the server, as it would take
> > over all deployments. Extensions that use the factory mechanism though can
> > be bundled in the server and exposed to all deployments, and the user
> > selects the mechanism to use via a standard descriptor.
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Stuart Douglas" <sdouglas at redhat.com>
> >> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >> Cc: undertow-dev at lists.jboss.org
> >> Sent: Friday, 13 December, 2013 8:29:17 AM
> >> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>
> >>
> >>>
> >>> You should remove that setJaspiAuthenticationMechanism and use the
> >>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
> >>> :)
> >>>
> >>> In my use case, I have a single authentication mechanism which I want to
> >>> use for the webapp
> >>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> >>>
> >>> That is it.
> >>>
> >>> I can use the Factory indirection that you have recently added but it is
> >>> counter intuitive and overkill for my use case.
> >>>
> >>> Users of undertow API will ask the same question or get confused if
> >>> their simple use cases such as mine are not covered with a direct
> >>> API method. :)
> >>
> >> Why do you want to completely override the method, and ignore whatever
> >> method
> >> a user has configured? In general I would prefer that mechanisms used the
> >> factory mechanism, so they all behave in a consistent manner. What is your
> >> use case that makes this not an option?
> >>
> >> Stuart
> >>
> >>>
> >>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> >>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From Anil.Saldhana at redhat.com  Fri Dec 13 09:59:23 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 08:59:23 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <657454061.36408243.1386920481108.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
Message-ID: <52AB20CB.6000209@redhat.com>

Hi Stuart,
   I view it from a pure DeploymentInfo API perspective. I am not 
thinking about extensions or servers. Right now, my runtime is a JUnit 
test operating on Undertow.

https://gist.github.com/anilsaldhana/7945498

I don't argue about the need for your factory for installing custom 
authentication mechanism for a particular deployment.  I am saying that 
is an overkill for cases where the authentication mechanism 
determination is done by the integrating project/layer - be it JUnit 
Tests or non-wildfly based servers. In that case, it would be ideal to 
have the additional method to install a particular authentication 
mechanism for the deployment.

Regards,
Anil

On 12/13/2013 01:41 AM, Stuart Douglas wrote:
> For a good example of extensions should just be using the factory mechanism, consider the case for extensions that are bundled with Wildfly.
>
> If an extension simply tries to take over a deployments authentication mechanism, then we could never bundle it in the server, as it would take over all deployments. Extensions that use the factory mechanism though can be bundled in the server and exposed to all deployments, and the user selects the mechanism to use via a standard descriptor.
>
> Stuart
>
> ----- Original Message -----
>> From: "Stuart Douglas" <sdouglas at redhat.com>
>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Friday, 13 December, 2013 8:29:17 AM
>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>
>>
>>> You should remove that setJaspiAuthenticationMechanism and use the
>>> setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
>>>
>>> In my use case, I have a single authentication mechanism which I want to
>>> use for the webapp
>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>
>>> That is it.
>>>
>>> I can use the Factory indirection that you have recently added but it is
>>> counter intuitive and overkill for my use case.
>>>
>>> Users of undertow API will ask the same question or get confused if
>>> their simple use cases such as mine are not covered with a direct
>>> API method. :)
>> Why do you want to completely override the method, and ignore whatever method
>> a user has configured? In general I would prefer that mechanisms used the
>> factory mechanism, so they all behave in a consistent manner. What is your
>> use case that makes this not an option?
>>
>> Stuart
>>
>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>> 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
>>>>>>>

From bburke at redhat.com  Fri Dec 13 10:07:56 2013
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Dec 2013 10:07:56 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
Message-ID: <52AB22CC.8030104@redhat.com>

Don't care that much about the convenience as long as it doesn't hinter 
implementation.  Superfluous APIs just bug me.  Just seems that 
AuthMechFactory is only usable for very simple cases that don't require 
access to metadata beyond the property map you pass or require adding 
additional handlers and/or mechanisms.

At this point though, I just want a stable API.

On 12/13/2013 9:58 AM, Stuart Douglas wrote:
> Ok, I have added some convenience methods.
>
> Now you can just do:
>
> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());
>
> Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Friday, 13 December, 2013 3:27:53 PM
>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>
>> This point is bogus.  You can write ServletExtensions that are triggered
>> only by metadata defined within a deployment.  I never understood why
>> you needed this extra SPI.
>>
>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
>> and I have to write an extension anyways.  I need to add additional
>> handlers that operate pre and post authentication.
>> AuthenticationMechanismFactory is just an additional level of
>> indirection I don't want or need.
>>
>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
>>> For a good example of extensions should just be using the factory
>>> mechanism, consider the case for extensions that are bundled with Wildfly.
>>>
>>> If an extension simply tries to take over a deployments authentication
>>> mechanism, then we could never bundle it in the server, as it would take
>>> over all deployments. Extensions that use the factory mechanism though can
>>> be bundled in the server and exposed to all deployments, and the user
>>> selects the mechanism to use via a standard descriptor.
>>>
>>> Stuart
>>>
>>> ----- Original Message -----
>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>> Cc: undertow-dev at lists.jboss.org
>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>
>>>>
>>>>>
>>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
>>>>> :)
>>>>>
>>>>> In my use case, I have a single authentication mechanism which I want to
>>>>> use for the webapp
>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>>
>>>>> That is it.
>>>>>
>>>>> I can use the Factory indirection that you have recently added but it is
>>>>> counter intuitive and overkill for my use case.
>>>>>
>>>>> Users of undertow API will ask the same question or get confused if
>>>>> their simple use cases such as mine are not covered with a direct
>>>>> API method. :)
>>>>
>>>> Why do you want to completely override the method, and ignore whatever
>>>> method
>>>> a user has configured? In general I would prefer that mechanisms used the
>>>> factory mechanism, so they all behave in a consistent manner. What is your
>>>> use case that makes this not an option?
>>>>
>>>> Stuart
>>>>
>>>>>
>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Fri Dec 13 10:08:33 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 09:08:33 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB20CB.6000209@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB20CB.6000209@redhat.com>
Message-ID: <52AB22F1.807@redhat.com>

On 12/13/2013 08:59 AM, Anil Saldhana wrote:
> Hi Stuart,
>     I view it from a pure DeploymentInfo API perspective. I am not
> thinking about extensions or servers. Right now, my runtime is a JUnit
> test operating on Undertow.
>
> https://gist.github.com/anilsaldhana/7945498
In the Jetty world, it would look like
https://github.com/anilsaldhana/picketlink-bindings/blob/undertow/picketlink-jetty-common/src/test/java/org/picketlink/test/identity/federation/bindings/jetty/SPInitiatedSSOWorkflowTestCase.java

SecurityHandler securityHandler = .....
securityHandler.setAuthenticator(myNewAuthenticator);

Jetty does have challenge/response mechanisms inbuilt into the core 
authenticators.

Tomcat and Jetty deals with the replacement of Authenticators. Undertow 
deals with AuthenticationMechanisms which may be many for a particular 
web app. There lies a mismatch.
An authenticator can have a gazillion auth mechanisms underneath.

>
> I don't argue about the need for your factory for installing custom
> authentication mechanism for a particular deployment.  I am saying that
> is an overkill for cases where the authentication mechanism
> determination is done by the integrating project/layer - be it JUnit
> Tests or non-wildfly based servers. In that case, it would be ideal to
> have the additional method to install a particular authentication
> mechanism for the deployment.
>
> Regards,
> Anil
>
> On 12/13/2013 01:41 AM, Stuart Douglas wrote:
>> For a good example of extensions should just be using the factory mechanism, consider the case for extensions that are bundled with Wildfly.
>>
>> If an extension simply tries to take over a deployments authentication mechanism, then we could never bundle it in the server, as it would take over all deployments. Extensions that use the factory mechanism though can be bundled in the server and exposed to all deployments, and the user selects the mechanism to use via a standard descriptor.
>>
>> Stuart
>>
>> ----- Original Message -----
>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> Cc: undertow-dev at lists.jboss.org
>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>
>>>
>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion. :)
>>>>
>>>> In my use case, I have a single authentication mechanism which I want to
>>>> use for the webapp
>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>
>>>> That is it.
>>>>
>>>> I can use the Factory indirection that you have recently added but it is
>>>> counter intuitive and overkill for my use case.
>>>>
>>>> Users of undertow API will ask the same question or get confused if
>>>> their simple use cases such as mine are not covered with a direct
>>>> API method. :)
>>> Why do you want to completely override the method, and ignore whatever method
>>> a user has configured? In general I would prefer that mechanisms used the
>>> factory mechanism, so they all behave in a consistent manner. What is your
>>> use case that makes this not an option?
>>>
>>> Stuart
>>>
>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>> 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
>>>>>>>>
>>>>>>>>

From Anil.Saldhana at redhat.com  Fri Dec 13 10:51:51 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 09:51:51 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
Message-ID: <52AB2D17.40501@redhat.com>

Stuart,
   I suggest getting rid of setJASPIAuthenticationMechanism(xyz) on the 
deployment info. You are basically tying an API method to a mechanism 
such as JASPI.

Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST, 
AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a 
string) and then use the addFirstAuthenticationMechanism() or 
setAuthenticationMechanism api to install this adhoc low demand jaspi 
mechanism. Users should be able to provide arbitrary string to the API 
method.

I am mainly viewing this from DeploymentInfo API aesthetics/usability 
perspective. To me, Undertow is a standalone web container (like Jetty) 
with an usable API (JUnit tests would be the litmus test).  
Extensions/WildFly etc come later.

Regards,
Anil

On 12/13/2013 08:58 AM, Stuart Douglas wrote:
> Ok, I have added some convenience methods.
>
> Now you can just do:
>
> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());
>
> Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.
>
> Stuart
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Friday, 13 December, 2013 3:27:53 PM
>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>
>> This point is bogus.  You can write ServletExtensions that are triggered
>> only by metadata defined within a deployment.  I never understood why
>> you needed this extra SPI.
>>
>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
>> and I have to write an extension anyways.  I need to add additional
>> handlers that operate pre and post authentication.
>> AuthenticationMechanismFactory is just an additional level of
>> indirection I don't want or need.
>>
>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
>>> For a good example of extensions should just be using the factory
>>> mechanism, consider the case for extensions that are bundled with Wildfly.
>>>
>>> If an extension simply tries to take over a deployments authentication
>>> mechanism, then we could never bundle it in the server, as it would take
>>> over all deployments. Extensions that use the factory mechanism though can
>>> be bundled in the server and exposed to all deployments, and the user
>>> selects the mechanism to use via a standard descriptor.
>>>
>>> Stuart
>>>
>>> ----- Original Message -----
>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>> Cc: undertow-dev at lists.jboss.org
>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>
>>>>
>>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
>>>>> :)
>>>>>
>>>>> In my use case, I have a single authentication mechanism which I want to
>>>>> use for the webapp
>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>>
>>>>> That is it.
>>>>>
>>>>> I can use the Factory indirection that you have recently added but it is
>>>>> counter intuitive and overkill for my use case.
>>>>>
>>>>> Users of undertow API will ask the same question or get confused if
>>>>> their simple use cases such as mine are not covered with a direct
>>>>> API method. :)
>>>> Why do you want to completely override the method, and ignore whatever
>>>> method
>>>> a user has configured? In general I would prefer that mechanisms used the
>>>> factory mechanism, so they all behave in a consistent manner. What is your
>>>> use case that makes this not an option?
>>>>
>>>> Stuart
>>>>
>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>>> 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
>>>>>>>
>>>>>>>   


From marc.boorshtein at tremolosecurity.com  Fri Dec 13 10:55:01 2013
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Fri, 13 Dec 2013 10:55:01 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB2D17.40501@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
Message-ID: <CAH2S7UB=UgDqzZWoHbWPFX82C0kZ22LDUYOcc2fw3TwzHr0rVg@mail.gmail.com>

>
> Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST,
> AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a
> string) and then use the addFirstAuthenticationMechanism() or
> setAuthenticationMechanism api to install this adhoc low demand jaspi
> mechanism. Users should be able to provide arbitrary string to the API
> method.
>
>
+1 I've been following this discussion and have written authentication
systems for JBoss, Tomcat, Weblogic, IIS, Apache, etc and having to
constrain to one of a few pre-defined methods is beyond frustrating.

Thanks
Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131213/1e932ad4/attachment.html 

From jason.greene at redhat.com  Fri Dec 13 11:08:04 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 13 Dec 2013 10:08:04 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <CAH2S7UB=UgDqzZWoHbWPFX82C0kZ22LDUYOcc2fw3TwzHr0rVg@mail.gmail.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
	<CAH2S7UB=UgDqzZWoHbWPFX82C0kZ22LDUYOcc2fw3TwzHr0rVg@mail.gmail.com>
Message-ID: <5614115A-EE0E-4C03-83F8-3361BC57AE70@redhat.com>


On Dec 13, 2013, at 9:55 AM, Marc Boorshtein <marc.boorshtein at tremolosecurity.com> wrote:

> 
> 
> 
> 
> Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST,
> AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a
> string) and then use the addFirstAuthenticationMechanism() or
> setAuthenticationMechanism api to install this adhoc low demand jaspi
> mechanism. Users should be able to provide arbitrary string to the API
> method.
> 
> 
> +1 I've been following this discussion and have written authentication systems for JBoss, Tomcat, Weblogic, IIS, Apache, etc and having to constrain to one of a few pre-defined methods is beyond frustrating.
> 

AFAICT thats never been an option (to limit the user to a canned auth mechanism). I think the intention was to allow for multiple authentication mechanisms to cooperate, and to allow for some uniformity in configuration and selection of them. It seems to be a tried and true concept (e.g. PAM). Although I think its great to nitpick the API. It should be as easy as possible.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From david.lloyd at redhat.com  Fri Dec 13 11:21:11 2013
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 13 Dec 2013 10:21:11 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB2D17.40501@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>	<52AAB155.4010503@redhat.com>	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>	<52AB1969.8050905@redhat.com>	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
Message-ID: <52AB33F7.60805@redhat.com>

On 12/13/2013 09:51 AM, Anil Saldhana wrote:
> I am mainly viewing this from DeploymentInfo API aesthetics/usability
> perspective.

No point in continuing then, as aesthetics is completely subjective by 
definition, and thus all answers are equally "right" or "wrong"; 
debating the finer points of API aesthetics is perhaps an amusing 
diversion but it is also a major time consumer.

See also http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

-- 
- DML

From jason.greene at redhat.com  Fri Dec 13 11:23:51 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 13 Dec 2013 10:23:51 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB22CC.8030104@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
Message-ID: <160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>

To Darran?s question though, do you ever see a valid use case for KeyCloak combining with other authentication mechanisms? 

Some admittedly poorly thought out examples:
1. The user wants to register additional IP restrictions
2. The user wants to reject requests with known malware headers
3. The user wants to limit the number of simultaneous sessions with a user id
4. The user wants to allow either password auth or SSO

If you do how should they do it? Keycloak SPI? Plain-ole Handlers? 
 
On Dec 13, 2013, at 9:07 AM, Bill Burke <bburke at redhat.com> wrote:

> Don't care that much about the convenience as long as it doesn't hinter 
> implementation.  Superfluous APIs just bug me.  Just seems that 
> AuthMechFactory is only usable for very simple cases that don't require 
> access to metadata beyond the property map you pass or require adding 
> additional handlers and/or mechanisms.
> 
> At this point though, I just want a stable API.
> 
> On 12/13/2013 9:58 AM, Stuart Douglas wrote:
>> Ok, I have added some convenience methods.
>> 
>> Now you can just do:
>> 
>> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());
>> 
>> Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.
>> 
>> Stuart
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: undertow-dev at lists.jboss.org
>>> Sent: Friday, 13 December, 2013 3:27:53 PM
>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>> 
>>> This point is bogus.  You can write ServletExtensions that are triggered
>>> only by metadata defined within a deployment.  I never understood why
>>> you needed this extra SPI.
>>> 
>>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
>>> and I have to write an extension anyways.  I need to add additional
>>> handlers that operate pre and post authentication.
>>> AuthenticationMechanismFactory is just an additional level of
>>> indirection I don't want or need.
>>> 
>>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
>>>> For a good example of extensions should just be using the factory
>>>> mechanism, consider the case for extensions that are bundled with Wildfly.
>>>> 
>>>> If an extension simply tries to take over a deployments authentication
>>>> mechanism, then we could never bundle it in the server, as it would take
>>>> over all deployments. Extensions that use the factory mechanism though can
>>>> be bundled in the server and exposed to all deployments, and the user
>>>> selects the mechanism to use via a standard descriptor.
>>>> 
>>>> Stuart
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>> Cc: undertow-dev at lists.jboss.org
>>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>> 
>>>>> 
>>>>>> 
>>>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
>>>>>> :)
>>>>>> 
>>>>>> In my use case, I have a single authentication mechanism which I want to
>>>>>> use for the webapp
>>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>>> 
>>>>>> That is it.
>>>>>> 
>>>>>> I can use the Factory indirection that you have recently added but it is
>>>>>> counter intuitive and overkill for my use case.
>>>>>> 
>>>>>> Users of undertow API will ask the same question or get confused if
>>>>>> their simple use cases such as mine are not covered with a direct
>>>>>> API method. :)
>>>>> 
>>>>> Why do you want to completely override the method, and ignore whatever
>>>>> method
>>>>> a user has configured? In general I would prefer that mechanisms used the
>>>>> factory mechanism, so they all behave in a consistent manner. What is your
>>>>> use case that makes this not an option?
>>>>> 
>>>>> Stuart
>>>>> 
>>>>>> 
>>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>>>> 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
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> undertow-dev mailing list
>>>>>>> undertow-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>> 
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>> 
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>> 
>>> 
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From Anil.Saldhana at redhat.com  Fri Dec 13 11:25:55 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 10:25:55 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB33F7.60805@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>	<52AAB155.4010503@redhat.com>	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>	<52AB1969.8050905@redhat.com>	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com> <52AB33F7.60805@redhat.com>
Message-ID: <52AB3513.5080500@redhat.com>

On 12/13/2013 10:21 AM, David M. Lloyd wrote:
> On 12/13/2013 09:51 AM, Anil Saldhana wrote:
>> I am mainly viewing this from DeploymentInfo API aesthetics/usability
>> perspective.
> No point in continuing then, as aesthetics is completely subjective by
> definition, and thus all answers are equally "right" or "wrong";
> debating the finer points of API aesthetics is perhaps an amusing
> diversion but it is also a major time consumer.
>
> See also http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
>
Sure - if Undertow is a project that caters to a small set of 
integrators and expected to have
a very short shelf life, then yes, the discussion is pointless.  But ... 
as Tomcat and Jetty have shown,
Java based web containers have a long shelf life.  API design becomes 
paramount. :)



From Anil.Saldhana at redhat.com  Fri Dec 13 11:00:04 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 10:00:04 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <CAH2S7UB=UgDqzZWoHbWPFX82C0kZ22LDUYOcc2fw3TwzHr0rVg@mail.gmail.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
	<CAH2S7UB=UgDqzZWoHbWPFX82C0kZ22LDUYOcc2fw3TwzHr0rVg@mail.gmail.com>
Message-ID: <52AB2F04.5000303@redhat.com>

On 12/13/2013 09:55 AM, Marc Boorshtein wrote:
>
>
>
>
>     Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST,
>     AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is
>     just a
>     string) and then use the addFirstAuthenticationMechanism() or
>     setAuthenticationMechanism api to install this adhoc low demand jaspi
>     mechanism. Users should be able to provide arbitrary string to the API
>     method.
>
>
> +1 I've been following this discussion and have written authentication 
> systems for JBoss, Tomcat, Weblogic, IIS, Apache, etc and having to 
> constrain to one of a few pre-defined methods is beyond frustrating.
>
> Thanks
> Marc

Hi Marc,
   API design is a hard science anyway.  There are enough theses written 
on the design, update and compatibility of APIs over the years.
http://wiki.eclipse.org/Evolving_Java-based_APIs

I cannot claim that I understand it completely myself. :)

Regards,
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131213/dc1243fe/attachment-0001.html 

From jason.greene at redhat.com  Fri Dec 13 11:38:26 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 13 Dec 2013 10:38:26 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB2D17.40501@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
Message-ID: <42426263-8D01-46B4-A752-185D6527CA95@redhat.com>


On Dec 13, 2013, at 9:51 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Stuart,
>   I suggest getting rid of setJASPIAuthenticationMechanism(xyz) on the 
> deployment info. You are basically tying an API method to a mechanism 
> such as JASPI.

I am not sure why it?s separate either. Is it just for convenience? 

> 
> Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST, 
> AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a 
> string) and then use the addFirstAuthenticationMechanism() or 
> setAuthenticationMechanism api to install this adhoc low demand jaspi 
> mechanism. Users should be able to provide arbitrary string to the API 
> method.

An enum would be nice, however, it might be confusing mixing Strings and 
enums since they are a closed set. There should definitely be some constant
mechanism though.

> 
> I am mainly viewing this from DeploymentInfo API aesthetics/usability 
> perspective. To me, Undertow is a standalone web container (like Jetty) 
> with an usable API (JUnit tests would be the litmus test).  
> Extensions/WildFly etc come later.

IMO auth extensions are useful in the standalone case as well. I think
it?s likely that most users do not write custom auth mechanisms, but 
simply want to reuse packaged or thirdparty auth in as few steps as possible.


> 
> Regards,
> Anil
> 
> On 12/13/2013 08:58 AM, Stuart Douglas wrote:
>> Ok, I have added some convenience methods.
>> 
>> Now you can just do:
>> 
>> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());
>> 
>> Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.
>> 
>> Stuart
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: undertow-dev at lists.jboss.org
>>> Sent: Friday, 13 December, 2013 3:27:53 PM
>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>> 
>>> This point is bogus.  You can write ServletExtensions that are triggered
>>> only by metadata defined within a deployment.  I never understood why
>>> you needed this extra SPI.
>>> 
>>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
>>> and I have to write an extension anyways.  I need to add additional
>>> handlers that operate pre and post authentication.
>>> AuthenticationMechanismFactory is just an additional level of
>>> indirection I don't want or need.
>>> 
>>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
>>>> For a good example of extensions should just be using the factory
>>>> mechanism, consider the case for extensions that are bundled with Wildfly.
>>>> 
>>>> If an extension simply tries to take over a deployments authentication
>>>> mechanism, then we could never bundle it in the server, as it would take
>>>> over all deployments. Extensions that use the factory mechanism though can
>>>> be bundled in the server and exposed to all deployments, and the user
>>>> selects the mechanism to use via a standard descriptor.
>>>> 
>>>> Stuart
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>> Cc: undertow-dev at lists.jboss.org
>>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>> 
>>>>> 
>>>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
>>>>>> :)
>>>>>> 
>>>>>> In my use case, I have a single authentication mechanism which I want to
>>>>>> use for the webapp
>>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>>> 
>>>>>> That is it.
>>>>>> 
>>>>>> I can use the Factory indirection that you have recently added but it is
>>>>>> counter intuitive and overkill for my use case.
>>>>>> 
>>>>>> Users of undertow API will ask the same question or get confused if
>>>>>> their simple use cases such as mine are not covered with a direct
>>>>>> API method. :)
>>>>> Why do you want to completely override the method, and ignore whatever
>>>>> method
>>>>> a user has configured? In general I would prefer that mechanisms used the
>>>>> factory mechanism, so they all behave in a consistent manner. What is your
>>>>> use case that makes this not an option?
>>>>> 
>>>>> Stuart
>>>>> 
>>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Fri Dec 13 11:47:26 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 13 Dec 2013 10:47:26 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB3513.5080500@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>	<52AAB155.4010503@redhat.com>	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>	<52AB1969.8050905@redhat.com>	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com> <52AB33F7.60805@redhat.com>
	<52AB3513.5080500@redhat.com>
Message-ID: <D1F2E89F-DBBE-4C0C-9830-0E6666A315E9@redhat.com>


On Dec 13, 2013, at 10:25 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> On 12/13/2013 10:21 AM, David M. Lloyd wrote:
>> On 12/13/2013 09:51 AM, Anil Saldhana wrote:
>>> I am mainly viewing this from DeploymentInfo API aesthetics/usability
>>> perspective.
>> No point in continuing then, as aesthetics is completely subjective by
>> definition, and thus all answers are equally "right" or "wrong";
>> debating the finer points of API aesthetics is perhaps an amusing
>> diversion but it is also a major time consumer.
>> 
>> See also http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
>> 
> Sure - if Undertow is a project that caters to a small set of 
> integrators and expected to have
> a very short shelf life, then yes, the discussion is pointless.  But ... 
> as Tomcat and Jetty have shown,
> Java based web containers have a long shelf life.  API design becomes 
> paramount. :)

I want the API to be awesome too :) Note that Stuart is looking for feedback for
all of the Undertow APIs (not just this) before it goes final. This is our 
one-and-only chance to get them right.

Hearing the top 10 API annoyances from everyone would be awesome!

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From marc.boorshtein at tremolosecurity.com  Fri Dec 13 11:51:33 2013
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Fri, 13 Dec 2013 11:51:33 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <42426263-8D01-46B4-A752-185D6527CA95@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
	<42426263-8D01-46B4-A752-185D6527CA95@redhat.com>
Message-ID: <CAH2S7UCKGOBdJoa=YBD2j20N_hVGgoHqXBN_ixT+=3Yc4g+ZjQ@mail.gmail.com>

>
>
> >
> > I am mainly viewing this from DeploymentInfo API aesthetics/usability
> > perspective. To me, Undertow is a standalone web container (like Jetty)
> > with an usable API (JUnit tests would be the litmus test).
> > Extensions/WildFly etc come later.
>
> IMO auth extensions are useful in the standalone case as well. I think
> it?s likely that most users do not write custom auth mechanisms, but
> simply want to reuse packaged or thirdparty auth in as few steps as
> possible.
>
>
>
>
With one caveat...External SSO/Web Access Management systems.  Most
commercial WAMs (ie SiteMinder, OpenAM, Oracle Access Manager, etc) rely on
cookies for session management, usually with a reverse proxy model (there's
an agent in the web server that controls all of the redirects to central
authentication and the by the time the connection gets to the app server
the user is already authenticated).  So in an environment with  a WAM the
easiest thing to do is tell your app server to use some local component to
"trust" the authentication from the proxy.  In weblogic this is done via
the IdentityAsserter api.  In WebSphere the TAI.  Tomcat doesn't have a
specific mechanism for this, I just do it in a Valve or Servlet Filter.
 I've done it with older JBoss versions with JAAS plugins and Servlet
Filters that I had a difficult time trying to work with.  A simple way to
specify an identity asserter of some kind for offloaded authentication
would be very helpful.

Thanks
Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131213/c6b07eaf/attachment.html 

From Anil.Saldhana at redhat.com  Fri Dec 13 11:58:30 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 13 Dec 2013 10:58:30 -0600
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <D1F2E89F-DBBE-4C0C-9830-0E6666A315E9@redhat.com>
References: <52AA3468.9020609@redhat.com>	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>	<52AA456A.3020205@redhat.com>	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>	<52AAB155.4010503@redhat.com>	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>	<52AB1969.8050905@redhat.com>	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com> <52AB33F7.60805@redhat.com>
	<52AB3513.5080500@redhat.com>
	<D1F2E89F-DBBE-4C0C-9830-0E6666A315E9@redhat.com>
Message-ID: <52AB3CB6.2000906@redhat.com>

On 12/13/2013 10:47 AM, Jason Greene wrote:
>>> >>See alsohttp://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
>>> >>
>> >Sure - if Undertow is a project that caters to a small set of
>> >integrators and expected to have
>> >a very short shelf life, then yes, the discussion is pointless.  But ...
>> >as Tomcat and Jetty have shown,
>> >Java based web containers have a long shelf life.  API design becomes
>> >paramount.:)
> I want the API to be awesome too:)  Note that Stuart is looking for feedback for
> all of the Undertow APIs (not just this) before it goes final. This is our
> one-and-only chance to get them right.
>
> Hearing the top 10 API annoyances from everyone would be awesome!
I will do my best to raise my voice. :)  I have one other minor 
annoyance with respect
to ChallengeResult API coming in a separate email thread.

From bburke at redhat.com  Fri Dec 13 13:34:00 2013
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Dec 2013 13:34:00 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<666709521.36264491.1386890068982.JavaMail.root@redhat.com>
	<52AA456A.3020205@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
Message-ID: <52AB5318.5070106@redhat.com>






On 12/13/2013 11:23 AM, Jason Greene wrote:
> To Darran?s question though, do you ever see a valid use case for KeyCloak combining with other authentication mechanisms?
>

Keycloak can be combined with other auth mechanisms.

> If you do how should they do it? Keycloak SPI? Plain-ole Handlers?
>

Through standard Undertow SPIs/config.

Specifying an web.xml <auth-method> of "KEYCLOAK" would add multiple 
AuthMechanisms and handlers.  I do this through the ServletExtension SPI.

Besides AuthMechnanisms, I need need additional handlers to do preflight 
cors (runs before authentication) and handlers that run after 
authentication: CORS origin validation, remote session and adapter mgmt 
URIs, and other security related REST apis that the adapter provides.



> On Dec 13, 2013, at 9:07 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Don't care that much about the convenience as long as it doesn't hinter
>> implementation.  Superfluous APIs just bug me.  Just seems that
>> AuthMechFactory is only usable for very simple cases that don't require
>> access to metadata beyond the property map you pass or require adding
>> additional handlers and/or mechanisms.
>>
>> At this point though, I just want a stable API.
>>
>> On 12/13/2013 9:58 AM, Stuart Douglas wrote:
>>> Ok, I have added some convenience methods.
>>>
>>> Now you can just do:
>>>
>>> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new OAuthAuthenticationMechanism());
>>>
>>> Behind the scenes it is still the same thing though. Basically the first call clears out any configured auth methods, and the second registers a factory that just returns the same instance, and then adds it to the start of the authentication mechanisms list.
>>>
>>> Stuart
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: undertow-dev at lists.jboss.org
>>>> Sent: Friday, 13 December, 2013 3:27:53 PM
>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>
>>>> This point is bogus.  You can write ServletExtensions that are triggered
>>>> only by metadata defined within a deployment.  I never understood why
>>>> you needed this extra SPI.
>>>>
>>>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
>>>> and I have to write an extension anyways.  I need to add additional
>>>> handlers that operate pre and post authentication.
>>>> AuthenticationMechanismFactory is just an additional level of
>>>> indirection I don't want or need.
>>>>
>>>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
>>>>> For a good example of extensions should just be using the factory
>>>>> mechanism, consider the case for extensions that are bundled with Wildfly.
>>>>>
>>>>> If an extension simply tries to take over a deployments authentication
>>>>> mechanism, then we could never bundle it in the server, as it would take
>>>>> over all deployments. Extensions that use the factory mechanism though can
>>>>> be bundled in the server and exposed to all deployments, and the user
>>>>> selects the mechanism to use via a standard descriptor.
>>>>>
>>>>> Stuart
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
>>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>>> Cc: undertow-dev at lists.jboss.org
>>>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
>>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> You should remove that setJaspiAuthenticationMechanism and use the
>>>>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
>>>>>>> :)
>>>>>>>
>>>>>>> In my use case, I have a single authentication mechanism which I want to
>>>>>>> use for the webapp
>>>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
>>>>>>>
>>>>>>> That is it.
>>>>>>>
>>>>>>> I can use the Factory indirection that you have recently added but it is
>>>>>>> counter intuitive and overkill for my use case.
>>>>>>>
>>>>>>> Users of undertow API will ask the same question or get confused if
>>>>>>> their simple use cases such as mine are not covered with a direct
>>>>>>> API method. :)
>>>>>>
>>>>>> Why do you want to completely override the method, and ignore whatever
>>>>>> method
>>>>>> a user has configured? In general I would prefer that mechanisms used the
>>>>>> factory mechanism, so they all behave in a consistent manner. What is your
>>>>>> use case that makes this not an option?
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>>>
>>>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
>>>>>>>> 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
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> undertow-dev mailing list
>>>>>>>> undertow-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> undertow-dev mailing list
>>>>>>> undertow-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Dec 13 15:32:59 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 15:32:59 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB2D17.40501@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<1403429648.36402703.1386917580592.JavaMail.root@redhat.com>
	<52AAB155.4010503@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB2D17.40501@redhat.com>
Message-ID: <1622152110.37238977.1386966779860.JavaMail.root@redhat.com>

JASPI has special requirements. Basically that method is needed to integrate with WF JASPIC support, otherwise just don't use it.

Stuart

----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Friday, 13 December, 2013 4:51:51 PM
> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> 
> Stuart,
>    I suggest getting rid of setJASPIAuthenticationMechanism(xyz) on the
> deployment info. You are basically tying an API method to a mechanism
> such as JASPI.
> 
> Have an enum on the auth method (Authmethod.FORM, AuthMethod.DIGEST,
> AuthMethod.BASIC, AuthMethod.JASPI) (The web.xml login-method is just a
> string) and then use the addFirstAuthenticationMechanism() or
> setAuthenticationMechanism api to install this adhoc low demand jaspi
> mechanism. Users should be able to provide arbitrary string to the API
> method.
> 
> I am mainly viewing this from DeploymentInfo API aesthetics/usability
> perspective. To me, Undertow is a standalone web container (like Jetty)
> with an usable API (JUnit tests would be the litmus test).
> Extensions/WildFly etc come later.
> 
> Regards,
> Anil
> 
> On 12/13/2013 08:58 AM, Stuart Douglas wrote:
> > Ok, I have added some convenience methods.
> >
> > Now you can just do:
> >
> > d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new
> > OAuthAuthenticationMechanism());
> >
> > Behind the scenes it is still the same thing though. Basically the first
> > call clears out any configured auth methods, and the second registers a
> > factory that just returns the same instance, and then adds it to the start
> > of the authentication mechanisms list.
> >
> > Stuart
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: undertow-dev at lists.jboss.org
> >> Sent: Friday, 13 December, 2013 3:27:53 PM
> >> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>
> >> This point is bogus.  You can write ServletExtensions that are triggered
> >> only by metadata defined within a deployment.  I never understood why
> >> you needed this extra SPI.
> >>
> >> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
> >> and I have to write an extension anyways.  I need to add additional
> >> handlers that operate pre and post authentication.
> >> AuthenticationMechanismFactory is just an additional level of
> >> indirection I don't want or need.
> >>
> >> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
> >>> For a good example of extensions should just be using the factory
> >>> mechanism, consider the case for extensions that are bundled with
> >>> Wildfly.
> >>>
> >>> If an extension simply tries to take over a deployments authentication
> >>> mechanism, then we could never bundle it in the server, as it would take
> >>> over all deployments. Extensions that use the factory mechanism though
> >>> can
> >>> be bundled in the server and exposed to all deployments, and the user
> >>> selects the mechanism to use via a standard descriptor.
> >>>
> >>> Stuart
> >>>
> >>> ----- Original Message -----
> >>>> From: "Stuart Douglas" <sdouglas at redhat.com>
> >>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>>> Cc: undertow-dev at lists.jboss.org
> >>>> Sent: Friday, 13 December, 2013 8:29:17 AM
> >>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>
> >>>>
> >>>>> You should remove that setJaspiAuthenticationMechanism and use the
> >>>>> setAuthenticationMechanism(string,authmech) format. That is my opinion.
> >>>>> :)
> >>>>>
> >>>>> In my use case, I have a single authentication mechanism which I want
> >>>>> to
> >>>>> use for the webapp
> >>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> >>>>>
> >>>>> That is it.
> >>>>>
> >>>>> I can use the Factory indirection that you have recently added but it
> >>>>> is
> >>>>> counter intuitive and overkill for my use case.
> >>>>>
> >>>>> Users of undertow API will ask the same question or get confused if
> >>>>> their simple use cases such as mine are not covered with a direct
> >>>>> API method. :)
> >>>> Why do you want to completely override the method, and ignore whatever
> >>>> method
> >>>> a user has configured? In general I would prefer that mechanisms used
> >>>> the
> >>>> factory mechanism, so they all behave in a consistent manner. What is
> >>>> your
> >>>> use case that makes this not an option?
> >>>>
> >>>> Stuart
> >>>>
> >>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> >>>>>> 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
> >>>>>>>
> >>>>>>>   
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From sdouglas at redhat.com  Fri Dec 13 16:02:06 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 13 Dec 2013 16:02:06 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB5318.5070106@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
Message-ID: <2140061942.37251129.1386968526231.JavaMail.root@redhat.com>


> 
> 
> On 12/13/2013 11:23 AM, Jason Greene wrote:
> > To Darran?s question though, do you ever see a valid use case for KeyCloak
> > combining with other authentication mechanisms?
> >
> 
> Keycloak can be combined with other auth mechanisms.
> 
> > If you do how should they do it? Keycloak SPI? Plain-ole Handlers?
> >
> 
> Through standard Undertow SPIs/config.
> 
> Specifying an web.xml <auth-method> of "KEYCLOAK" would add multiple
> AuthMechanisms and handlers.  I do this through the ServletExtension SPI.


Ok, I have added another utility method, isAuthenticationMechanismPresent(String name).

So now the code to do this is basically:

if(d.isAuthenticationMechanismPresent("KEYCLOAK")) {
  d.addAuthenticationMechanism("KEYCLOAK", keycloadFactory);
  //add handlers and stuff
}

The reason why this is better that just adding you auth mechanism is because Undertow now controls the order. In the old
way of doing things if the user had specified something like:

BASIC?silent=true,KEYCLOAK,SSO

There is simply no way for extensions to parse that string and install themselves in the correct order (and order is very important). For one thing all the extension have to parse it in the exact same way, but more importantly because there is no ordering between extensions, there is no reliable way for an extension to figure out where it has to insert itself in the mechanism list.

With the factory SPI, this is all taken care of for you, all you have to do is register it under the correct name, and undertow takes care of the rest.

Basically have a security SPI that is capable of handling multiple mechanisms buys you nothing if you have no way of reliably configuring said mechanisms.

Stuart



> 
> Besides AuthMechnanisms, I need need additional handlers to do preflight
> cors (runs before authentication) and handlers that run after
> authentication: CORS origin validation, remote session and adapter mgmt
> URIs, and other security related REST apis that the adapter provides.
> 
> 
> 
> > On Dec 13, 2013, at 9:07 AM, Bill Burke <bburke at redhat.com> wrote:
> >
> >> Don't care that much about the convenience as long as it doesn't hinter
> >> implementation.  Superfluous APIs just bug me.  Just seems that
> >> AuthMechFactory is only usable for very simple cases that don't require
> >> access to metadata beyond the property map you pass or require adding
> >> additional handlers and/or mechanisms.
> >>
> >> At this point though, I just want a stable API.
> >>
> >> On 12/13/2013 9:58 AM, Stuart Douglas wrote:
> >>> Ok, I have added some convenience methods.
> >>>
> >>> Now you can just do:
> >>>
> >>> d.clearLoginMethods().addFirstAuthenticationMechanism("OAUTH", new
> >>> OAuthAuthenticationMechanism());
> >>>
> >>> Behind the scenes it is still the same thing though. Basically the first
> >>> call clears out any configured auth methods, and the second registers a
> >>> factory that just returns the same instance, and then adds it to the
> >>> start of the authentication mechanisms list.
> >>>
> >>> Stuart
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: undertow-dev at lists.jboss.org
> >>>> Sent: Friday, 13 December, 2013 3:27:53 PM
> >>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>
> >>>> This point is bogus.  You can write ServletExtensions that are triggered
> >>>> only by metadata defined within a deployment.  I never understood why
> >>>> you needed this extra SPI.
> >>>>
> >>>> Also, at least in my Keycloak case, AuthMechFactory isn't enough for me
> >>>> and I have to write an extension anyways.  I need to add additional
> >>>> handlers that operate pre and post authentication.
> >>>> AuthenticationMechanismFactory is just an additional level of
> >>>> indirection I don't want or need.
> >>>>
> >>>> On 12/13/2013 2:41 AM, Stuart Douglas wrote:
> >>>>> For a good example of extensions should just be using the factory
> >>>>> mechanism, consider the case for extensions that are bundled with
> >>>>> Wildfly.
> >>>>>
> >>>>> If an extension simply tries to take over a deployments authentication
> >>>>> mechanism, then we could never bundle it in the server, as it would
> >>>>> take
> >>>>> over all deployments. Extensions that use the factory mechanism though
> >>>>> can
> >>>>> be bundled in the server and exposed to all deployments, and the user
> >>>>> selects the mechanism to use via a standard descriptor.
> >>>>>
> >>>>> Stuart
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Stuart Douglas" <sdouglas at redhat.com>
> >>>>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>>>>> Cc: undertow-dev at lists.jboss.org
> >>>>>> Sent: Friday, 13 December, 2013 8:29:17 AM
> >>>>>> Subject: Re: [undertow-dev] AuthenticationMechanismFactory
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> You should remove that setJaspiAuthenticationMechanism and use the
> >>>>>>> setAuthenticationMechanism(string,authmech) format. That is my
> >>>>>>> opinion.
> >>>>>>> :)
> >>>>>>>
> >>>>>>> In my use case, I have a single authentication mechanism which I want
> >>>>>>> to
> >>>>>>> use for the webapp
> >>>>>>> deploymentInfo.setAuthenticationMechanism(myAuthenticationMechanism).setIgnoreStandardAuthenticationMechanism(true);
> >>>>>>>
> >>>>>>> That is it.
> >>>>>>>
> >>>>>>> I can use the Factory indirection that you have recently added but it
> >>>>>>> is
> >>>>>>> counter intuitive and overkill for my use case.
> >>>>>>>
> >>>>>>> Users of undertow API will ask the same question or get confused if
> >>>>>>> their simple use cases such as mine are not covered with a direct
> >>>>>>> API method. :)
> >>>>>>
> >>>>>> Why do you want to completely override the method, and ignore whatever
> >>>>>> method
> >>>>>> a user has configured? In general I would prefer that mechanisms used
> >>>>>> the
> >>>>>> factory mechanism, so they all behave in a consistent manner. What is
> >>>>>> your
> >>>>>> use case that makes this not an option?
> >>>>>>
> >>>>>> Stuart
> >>>>>>
> >>>>>>>
> >>>>>>> On 12/13/2013 12:53 AM, Stuart Douglas wrote:
> >>>>>>>> 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
> >>>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> undertow-dev mailing list
> >>>>>>>> undertow-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> undertow-dev mailing list
> >>>>>>> undertow-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> undertow-dev mailing list
> >>>>>> undertow-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>>
> >>>>> _______________________________________________
> >>>>> undertow-dev mailing list
> >>>>> undertow-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>


From bburke at redhat.com  Fri Dec 13 18:16:44 2013
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Dec 2013 18:16:44 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<1041608808.36407211.1386919757144.JavaMail.root@redhat.com>
	<657454061.36408243.1386920481108.JavaMail.root@redhat.com>
	<52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
Message-ID: <52AB955C.3030602@redhat.com>



On 12/13/2013 4:02 PM, Stuart Douglas wrote:
> The reason why this is better that just adding you auth mechanism is because Undertow now controls the order. In the old
> way of doing things if the user had specified something like:
>
> BASIC?silent=true,KEYCLOAK,SSO
>
> There is simply no way for extensions to parse that string and install themselves in the correct order (and order is very important). For one thing all the extension have to parse it in the exact same way, but more importantly because there is no ordering between extensions, there is no reliable way for an extension to figure out where it has to insert itself in the mechanism list.
>

What does ordering have to do with AuthMechFactory?  Are you planning an 
additional META-INF/services mechanism for AuthMechFactorys?  If not, 
how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what 
is the point of the AuthMechFactory when all the construction can be 
done within the ServletExtension?

But, while we're talking about ordering...

For Keycloak there's an "oauth redirect" mechanism that sends a 302 
response back for its challenge.  The way the Undertow logic works now, 
if this mechanism isn't first, the 302 status code will never be sent 
back, it will never work and you might as well not even list the 
mechanism.  Either my ServletExtension can force it to be first by 
calling LoginConfig.addFirst(), or it can throw a deployment exception.

BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it 
won't confuse the User-Agent.  Maybe the ChallengeResult should specify 
whether iteration of the mechanisms should continue.

Finally, I'm assuming that <auth-method>Basic, Keycloak, 
SSO</auth-method> will fill up the LoginConfig object thats available in 
DeploymentInfo?  Is it ok for the KeycloakServletExtension to remove 
"KEYCLOAK" from LoginConfig and add two new ones?  Looks like I can, 
just want to make sure any undocumented contract isn't going to be 
enforced in the future.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Sat Dec 14 05:33:20 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sat, 14 Dec 2013 05:33:20 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AB955C.3030602@redhat.com>
References: <52AA3468.9020609@redhat.com> <52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
	<52AB955C.3030602@redhat.com>
Message-ID: <1816266112.37318097.1387017200025.JavaMail.root@redhat.com>


> What does ordering have to do with AuthMechFactory?  Are you planning an
> additional META-INF/services mechanism for AuthMechFactorys?  If not,
> how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what
> is the point of the AuthMechFactory when all the construction can be
> done within the ServletExtension?

Because you can have multiple servlet extensions. This way undertow controls the order. If both extensions just add themselves you have no defined order. 


> 
> But, while we're talking about ordering...
> 
> For Keycloak there's an "oauth redirect" mechanism that sends a 302
> response back for its challenge.  The way the Undertow logic works now,
> if this mechanism isn't first, the 302 status code will never be sent
> back, it will never work and you might as well not even list the
> mechanism.  Either my ServletExtension can force it to be first by
> calling LoginConfig.addFirst(), or it can throw a deployment exception.

As long as the mechanism beforehand does not specify a status code, your mechanism should be able to. This is a fundamental limitation of HTTP, and it does limit which mechanisms can be combined.

Basically some mechanisms are never going to be able to work together.

> 
> BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it
> won't confuse the User-Agent.  Maybe the ChallengeResult should specify
> whether iteration of the mechanisms should continue.
> 
> Finally, I'm assuming that <auth-method>Basic, Keycloak,
> SSO</auth-method> will fill up the LoginConfig object thats available in
> DeploymentInfo?  Is it ok for the KeycloakServletExtension to remove
> "KEYCLOAK" from LoginConfig and add two new ones?  Looks like I can,
> just want to make sure any undocumented contract isn't going to be
> enforced in the future.

Yes, that is fine. For the most part everything in DeploymentInfo is mutable.

Stuart

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon Dec 16 08:44:08 2013
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Dec 2013 08:44:08 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com> <52AB1969.8050905@redhat.com>
	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>
	<52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
	<52AB955C.3030602@redhat.com>
	<1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
Message-ID: <52AF03A8.8070109@redhat.com>



On 12/14/2013 5:33 AM, Stuart Douglas wrote:
>
>> What does ordering have to do with AuthMechFactory?  Are you planning an
>> additional META-INF/services mechanism for AuthMechFactorys?  If not,
>> how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what
>> is the point of the AuthMechFactory when all the construction can be
>> done within the ServletExtension?
>
> Because you can have multiple servlet extensions. This way undertow controls the order. If both extensions just add themselves you have no defined order.
>

Again, what does ordering have to do with requiring an AuthMechFactory 
interface?

MyServletExtension {
    di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
}

Why do i need a AuthMechFactory if the servlet extension is able to 
construct the AuthMech?  I just would never use AuthMechFactory as all 
config information is already available within the ServletExtension for 
me to construct the AuthMechanism.  In fact, there's much more metadata 
available within the ServletExtension than is passed to the AuthMechFactory.

>
>>
>> But, while we're talking about ordering...
>>
>> For Keycloak there's an "oauth redirect" mechanism that sends a 302
>> response back for its challenge.  The way the Undertow logic works now,
>> if this mechanism isn't first, the 302 status code will never be sent
>> back, it will never work and you might as well not even list the
>> mechanism.  Either my ServletExtension can force it to be first by
>> calling LoginConfig.addFirst(), or it can throw a deployment exception.
>
> As long as the mechanism beforehand does not specify a status code, your mechanism should be able to. This is a fundamental limitation of HTTP, and it does limit which mechanisms can be combined.
>

Multiple WWW-Authenticate headers are allowed i'm just not sure what a 
user-agent would do if it saw a code other than 401 with a response that 
contained these headers.

> Basically some mechanisms are never going to be able to work together.
>
>>
>> BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it
>> won't confuse the User-Agent.  Maybe the ChallengeResult should specify
>> whether iteration of the mechanisms should continue.
>>

Again, it would be great if a ChallengeResult could abort the 
sendChallenge loop.  It would suck if there was no workaround for cases 
that were sensitive to a strict response.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Mon Dec 16 10:33:21 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 16 Dec 2013 09:33:21 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
Message-ID: <52AF1D41.1070804@redhat.com>

Hi,
    can the authentication mechanism have a lifecycle based on the 
context lifecycle?

I need access to the ServletContext to look for deployment descriptors 
using the servletContext.getResourceAsStream() call.

I am thinking something along the lines of:

authenticationMechanism.start(ServletContext);
authenticationMechanis.stop();

This will give an opportunity for the authentication mechanism to 
initialize and finalize any resources.

Regards,
Anil

From darran.lofthouse at redhat.com  Mon Dec 16 10:35:35 2013
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Mon, 16 Dec 2013 15:35:35 +0000
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AF03A8.8070109@redhat.com>
References: <52AA3468.9020609@redhat.com>
	<52AB1969.8050905@redhat.com>	<2097737379.37028571.1386946695426.JavaMail.root@redhat.com>	<52AB22CC.8030104@redhat.com>	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>	<52AB5318.5070106@redhat.com>	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>	<52AB955C.3030602@redhat.com>	<1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
	<52AF03A8.8070109@redhat.com>
Message-ID: <52AF1DC7.6020907@redhat.com>

On 16/12/13 13:44, Bill Burke wrote:
> Again, it would be great if a ChallengeResult could abort the
> sendChallenge loop.  It would suck if there was no workaround for cases
> that were sensitive to a strict response.

I agree I will have a look at that one, I have seen a couple of cases 
now where it does make sense for a single mechanism to be the only one 
challenging.


From darran.lofthouse at jboss.com  Mon Dec 16 10:38:35 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 16 Dec 2013 15:38:35 +0000
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52AF1D41.1070804@redhat.com>
References: <52AF1D41.1070804@redhat.com>
Message-ID: <52AF1E7B.90705@jboss.com>

How is this authentication mechanism being added?

On 16/12/13 15:33, Anil Saldhana wrote:
> Hi,
>      can the authentication mechanism have a lifecycle based on the
> context lifecycle?
>
> I need access to the ServletContext to look for deployment descriptors
> using the servletContext.getResourceAsStream() call.
>
> I am thinking something along the lines of:
>
> authenticationMechanism.start(ServletContext);
> authenticationMechanis.stop();
>
> This will give an opportunity for the authentication mechanism to
> initialize and finalize any resources.
>
> Regards,
> Anil
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

From Anil.Saldhana at redhat.com  Mon Dec 16 10:41:32 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 16 Dec 2013 09:41:32 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52AF1E7B.90705@jboss.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
Message-ID: <52AF1F2C.5090404@redhat.com>

Right now, I just have a junit test.  I set the auth mechanism factory 
in the deployment info.

di.addAuthenticationMechanism("FORM" , 
SPFormAuthenticationMechanism.FACTORY);

Irrespective of how it is added, when the deployment start happens, 
undertow should try to start
the authentication mechanisms by providing a handle to the servlet 
context.  The authentication mechanism
may need to read deployment descriptors or set up internal resources.

Regards,
Anil

On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
> How is this authentication mechanism being added?
>
> On 16/12/13 15:33, Anil Saldhana wrote:
>> Hi,
>>       can the authentication mechanism have a lifecycle based on the
>> context lifecycle?
>>
>> I need access to the ServletContext to look for deployment descriptors
>> using the servletContext.getResourceAsStream() call.
>>
>> I am thinking something along the lines of:
>>
>> authenticationMechanism.start(ServletContext);
>> authenticationMechanis.stop();
>>
>> This will give an opportunity for the authentication mechanism to
>> initialize and finalize any resources.
>>
>> Regards,
>> Anil

From Anil.Saldhana at redhat.com  Mon Dec 16 10:44:11 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 16 Dec 2013 09:44:11 -0600
Subject: [undertow-dev] AuthenticationMechanism,
	ChallengeResult and Response Code
Message-ID: <52AF1FCB.60904@redhat.com>

Hi,
  I am wondering if a flag can be set in ChallengeResult such that 
undertow does not try to set the response code on the httpserverexchange 
before sending the challenge?

The reason is that an authentication mechanism may have already utilized 
the httpservletresponse object to set a response code such as:

===========
response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
response.sendRedirect(destination);
==============

Now since undertow tries to set a response code on the 
httpServerExchange, there is an error.

Regards,
Anil

From darran.lofthouse at jboss.com  Mon Dec 16 11:01:45 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 16 Dec 2013 16:01:45 +0000
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52AF1FCB.60904@redhat.com>
References: <52AF1FCB.60904@redhat.com>
Message-ID: <52AF23E9.40700@jboss.com>

This may come under the same area as the single challenge I just replied 
to Bill about.

For mechanisms that may behave in this way can we detect that they would 
want exclusivity from within the authenticate method?

On 16/12/13 15:44, Anil Saldhana wrote:
> Hi,
>    I am wondering if a flag can be set in ChallengeResult such that
> undertow does not try to set the response code on the httpserverexchange
> before sending the challenge?
>
> The reason is that an authentication mechanism may have already utilized
> the httpservletresponse object to set a response code such as:
>
> ===========
> response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
> response.sendRedirect(destination);
> ==============
>
> Now since undertow tries to set a response code on the
> httpServerExchange, there is an error.
>
> Regards,
> Anil
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

From bburke at redhat.com  Mon Dec 16 11:24:03 2013
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Dec 2013 11:24:03 -0500
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52AF23E9.40700@jboss.com>
References: <52AF1FCB.60904@redhat.com> <52AF23E9.40700@jboss.com>
Message-ID: <52AF2923.1080301@redhat.com>

FYI: For my case at least, I can co-exist with other Auth mechanisms, I 
just need to be able to abort the sendChallenge loop and make sure I can 
have my auth mechanism first in the sendChallenge loop (pretty sure that 
one is already there).

On 12/16/2013 11:01 AM, Darran Lofthouse wrote:
> This may come under the same area as the single challenge I just replied
> to Bill about.
>
> For mechanisms that may behave in this way can we detect that they would
> want exclusivity from within the authenticate method?
>
> On 16/12/13 15:44, Anil Saldhana wrote:
>> Hi,
>>     I am wondering if a flag can be set in ChallengeResult such that
>> undertow does not try to set the response code on the httpserverexchange
>> before sending the challenge?
>>
>> The reason is that an authentication mechanism may have already utilized
>> the httpservletresponse object to set a response code such as:
>>
>> ===========
>> response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
>> response.sendRedirect(destination);
>> ==============
>>
>> Now since undertow tries to set a response code on the
>> httpServerExchange, there is an error.
>>
>> Regards,
>> Anil
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Tue Dec 17 02:35:21 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 17 Dec 2013 02:35:21 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52AF03A8.8070109@redhat.com>
References: <52AA3468.9020609@redhat.com> <52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
	<52AB955C.3030602@redhat.com>
	<1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
	<52AF03A8.8070109@redhat.com>
Message-ID: <213723608.38345203.1387265721472.JavaMail.root@redhat.com>


> 
> On 12/14/2013 5:33 AM, Stuart Douglas wrote:
> >
> >> What does ordering have to do with AuthMechFactory?  Are you planning an
> >> additional META-INF/services mechanism for AuthMechFactorys?  If not,
> >> how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what
> >> is the point of the AuthMechFactory when all the construction can be
> >> done within the ServletExtension?
> >
> > Because you can have multiple servlet extensions. This way undertow
> > controls the order. If both extensions just add themselves you have no
> > defined order.
> >
> 
> Again, what does ordering have to do with requiring an AuthMechFactory
> interface?
> 
> MyServletExtension {
>     di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
> }
> 
> Why do i need a AuthMechFactory if the servlet extension is able to
> construct the AuthMech?  I just would never use AuthMechFactory as all
> config information is already available within the ServletExtension for
> me to construct the AuthMechanism.  In fact, there's much more metadata
> available within the ServletExtension than is passed to the AuthMechFactory.

Note that with my latest changes you can do exactly what you mention above (di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));).

I guess the only real thing it buys you is having the ability to configure the same mechanism with different properties, although I am not sure
if that is really something that anyone would ever want to do. 

It also makes reading the config properties easier, as they are passed directly to the factory, although I guess it is pretty easy to just retrieve them directly, especially if I just add a convenience method. 

So maybe it is not really worth having the factory concept, although given that you don't have to use it if you don't want to I am not sure if we should keep it or not.

Stuart


> 
> >
> >>
> >> But, while we're talking about ordering...
> >>
> >> For Keycloak there's an "oauth redirect" mechanism that sends a 302
> >> response back for its challenge.  The way the Undertow logic works now,
> >> if this mechanism isn't first, the 302 status code will never be sent
> >> back, it will never work and you might as well not even list the
> >> mechanism.  Either my ServletExtension can force it to be first by
> >> calling LoginConfig.addFirst(), or it can throw a deployment exception.
> >
> > As long as the mechanism beforehand does not specify a status code, your
> > mechanism should be able to. This is a fundamental limitation of HTTP, and
> > it does limit which mechanisms can be combined.
> >
> 
> Multiple WWW-Authenticate headers are allowed i'm just not sure what a
> user-agent would do if it saw a code other than 401 with a response that
> contained these headers.
> 
> > Basically some mechanisms are never going to be able to work together.
> >
> >>
> >> BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it
> >> won't confuse the User-Agent.  Maybe the ChallengeResult should specify
> >> whether iteration of the mechanisms should continue.
> >>
> 
> Again, it would be great if a ChallengeResult could abort the
> sendChallenge loop.  It would suck if there was no workaround for cases
> that were sensitive to a strict response.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From sdouglas at redhat.com  Tue Dec 17 02:38:32 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 17 Dec 2013 02:38:32 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52AF1F2C.5090404@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
Message-ID: <2041174427.38346430.1387265912479.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 16 December, 2013 4:41:32 PM
> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
> 
> Right now, I just have a junit test.  I set the auth mechanism factory
> in the deployment info.
> 
> di.addAuthenticationMechanism("FORM" ,
> SPFormAuthenticationMechanism.FACTORY);
> 
> Irrespective of how it is added, when the deployment start happens,
> undertow should try to start
> the authentication mechanisms by providing a handle to the servlet
> context.  The authentication mechanism
> may need to read deployment descriptors or set up internal resources.

The ServletExtension already has a reference to the ServletContext, you can just pass it in to your factory. 

I guess this is another argument against using the factory, vs just creating it in the ServletExtension.

Stuart

> 
> Regards,
> Anil
> 
> On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
> > How is this authentication mechanism being added?
> >
> > On 16/12/13 15:33, Anil Saldhana wrote:
> >> Hi,
> >>       can the authentication mechanism have a lifecycle based on the
> >> context lifecycle?
> >>
> >> I need access to the ServletContext to look for deployment descriptors
> >> using the servletContext.getResourceAsStream() call.
> >>
> >> I am thinking something along the lines of:
> >>
> >> authenticationMechanism.start(ServletContext);
> >> authenticationMechanis.stop();
> >>
> >> This will give an opportunity for the authentication mechanism to
> >> initialize and finalize any resources.
> >>
> >> Regards,
> >> Anil
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From Anil.Saldhana at redhat.com  Tue Dec 17 10:43:51 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 17 Dec 2013 09:43:51 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
Message-ID: <52B07137.9090400@redhat.com>

On 12/17/2013 01:38 AM, Stuart Douglas wrote:
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Monday, 16 December, 2013 4:41:32 PM
>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>
>> Right now, I just have a junit test.  I set the auth mechanism factory
>> in the deployment info.
>>
>> di.addAuthenticationMechanism("FORM" ,
>> SPFormAuthenticationMechanism.FACTORY);
>>
>> Irrespective of how it is added, when the deployment start happens,
>> undertow should try to start
>> the authentication mechanisms by providing a handle to the servlet
>> context.  The authentication mechanism
>> may need to read deployment descriptors or set up internal resources.
> The ServletExtension already has a reference to the ServletContext, you can just pass it in to your factory.
>
> I guess this is another argument against using the factory, vs just creating it in the ServletExtension.
Unfortunately my unit tests run in junit. I cannot integrate the 
ServletExtension mechanism which is
a wildfly based integration usecase. If PicketLink SAML SSO has to 
integrate with Undertow, the unit
tests have to run in JUnit like we do with Tomcat and Jetty.

Do you have goals for Undertow to be a standalone web container (like 
jetty) or it is just a web container
usable in Wildfly?

>
> Stuart
>
>> Regards,
>> Anil
>>
>> On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
>>> How is this authentication mechanism being added?
>>>
>>> On 16/12/13 15:33, Anil Saldhana wrote:
>>>> Hi,
>>>>        can the authentication mechanism have a lifecycle based on the
>>>> context lifecycle?
>>>>
>>>> I need access to the ServletContext to look for deployment descriptors
>>>> using the servletContext.getResourceAsStream() call.
>>>>
>>>> I am thinking something along the lines of:
>>>>
>>>> authenticationMechanism.start(ServletContext);
>>>> authenticationMechanis.stop();
>>>>
>>>> This will give an opportunity for the authentication mechanism to
>>>> initialize and finalize any resources.
>>>>
>>>> Regards,
>>>> Anil
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>


From jason.greene at redhat.com  Tue Dec 17 10:46:26 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Tue, 17 Dec 2013 09:46:26 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52B07137.9090400@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
	<52B07137.9090400@redhat.com>
Message-ID: <A9962F88-9C28-477D-A19E-77AE399A0CA4@redhat.com>


On Dec 17, 2013, at 9:43 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> On 12/17/2013 01:38 AM, Stuart Douglas wrote:
>> 
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> To: undertow-dev at lists.jboss.org
>>> Sent: Monday, 16 December, 2013 4:41:32 PM
>>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>> 
>>> Right now, I just have a junit test.  I set the auth mechanism factory
>>> in the deployment info.
>>> 
>>> di.addAuthenticationMechanism("FORM" ,
>>> SPFormAuthenticationMechanism.FACTORY);
>>> 
>>> Irrespective of how it is added, when the deployment start happens,
>>> undertow should try to start
>>> the authentication mechanisms by providing a handle to the servlet
>>> context.  The authentication mechanism
>>> may need to read deployment descriptors or set up internal resources.
>> The ServletExtension already has a reference to the ServletContext, you can just pass it in to your factory.
>> 
>> I guess this is another argument against using the factory, vs just creating it in the ServletExtension.
> Unfortunately my unit tests run in junit. I cannot integrate the 
> ServletExtension mechanism which is
> a wildfly based integration usecase. If PicketLink SAML SSO has to 
> integrate with Undertow, the unit
> tests have to run in JUnit like we do with Tomcat and Jetty.
> 
> Do you have goals for Undertow to be a standalone web container (like 
> jetty) or it is just a web container
> usable in Wildfly?

Definitely the former, and thats certainly a good point. 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From sdouglas at redhat.com  Tue Dec 17 10:54:21 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 17 Dec 2013 10:54:21 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52B07137.9090400@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
	<52B07137.9090400@redhat.com>
Message-ID: <6544426.38593624.1387295661751.JavaMail.root@redhat.com>

ServletExtension is usable in embedded deployments as well now. I recently added io.undertow.servlet.api.DeploymentInfo#addServletExtension, so you can manually add extensions to the deployment as well as discovering them.

Stuart



----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Tuesday, 17 December, 2013 4:43:51 PM
> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
> 
> On 12/17/2013 01:38 AM, Stuart Douglas wrote:
> >
> > ----- Original Message -----
> >> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >> To: undertow-dev at lists.jboss.org
> >> Sent: Monday, 16 December, 2013 4:41:32 PM
> >> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
> >>
> >> Right now, I just have a junit test.  I set the auth mechanism factory
> >> in the deployment info.
> >>
> >> di.addAuthenticationMechanism("FORM" ,
> >> SPFormAuthenticationMechanism.FACTORY);
> >>
> >> Irrespective of how it is added, when the deployment start happens,
> >> undertow should try to start
> >> the authentication mechanisms by providing a handle to the servlet
> >> context.  The authentication mechanism
> >> may need to read deployment descriptors or set up internal resources.
> > The ServletExtension already has a reference to the ServletContext, you can
> > just pass it in to your factory.
> >
> > I guess this is another argument against using the factory, vs just
> > creating it in the ServletExtension.
> Unfortunately my unit tests run in junit. I cannot integrate the
> ServletExtension mechanism which is
> a wildfly based integration usecase. If PicketLink SAML SSO has to
> integrate with Undertow, the unit
> tests have to run in JUnit like we do with Tomcat and Jetty.
> 
> Do you have goals for Undertow to be a standalone web container (like
> jetty) or it is just a web container
> usable in Wildfly?
> 
> >
> > Stuart
> >
> >> Regards,
> >> Anil
> >>
> >> On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
> >>> How is this authentication mechanism being added?
> >>>
> >>> On 16/12/13 15:33, Anil Saldhana wrote:
> >>>> Hi,
> >>>>        can the authentication mechanism have a lifecycle based on the
> >>>> context lifecycle?
> >>>>
> >>>> I need access to the ServletContext to look for deployment descriptors
> >>>> using the servletContext.getResourceAsStream() call.
> >>>>
> >>>> I am thinking something along the lines of:
> >>>>
> >>>> authenticationMechanism.start(ServletContext);
> >>>> authenticationMechanis.stop();
> >>>>
> >>>> This will give an opportunity for the authentication mechanism to
> >>>> initialize and finalize any resources.
> >>>>
> >>>> Regards,
> >>>> Anil
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> 
> 

From Anil.Saldhana at redhat.com  Tue Dec 17 10:58:06 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 17 Dec 2013 09:58:06 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <6544426.38593624.1387295661751.JavaMail.root@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
	<52B07137.9090400@redhat.com>
	<6544426.38593624.1387295661751.JavaMail.root@redhat.com>
Message-ID: <52B0748E.3030702@redhat.com>

On 12/17/2013 09:54 AM, Stuart Douglas wrote:
> ServletExtension is usable in embedded deployments as well now. I recently added io.undertow.servlet.api.DeploymentInfo#addServletExtension, so you can manually add extensions to the deployment as well as discovering them.
Do you have any unit tests that I can see the usage?

>
> Stuart
>
>
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: "Stuart Douglas" <sdouglas at redhat.com>
>> Cc: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 17 December, 2013 4:43:51 PM
>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>
>> On 12/17/2013 01:38 AM, Stuart Douglas wrote:
>>> ----- Original Message -----
>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>> To: undertow-dev at lists.jboss.org
>>>> Sent: Monday, 16 December, 2013 4:41:32 PM
>>>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>>>
>>>> Right now, I just have a junit test.  I set the auth mechanism factory
>>>> in the deployment info.
>>>>
>>>> di.addAuthenticationMechanism("FORM" ,
>>>> SPFormAuthenticationMechanism.FACTORY);
>>>>
>>>> Irrespective of how it is added, when the deployment start happens,
>>>> undertow should try to start
>>>> the authentication mechanisms by providing a handle to the servlet
>>>> context.  The authentication mechanism
>>>> may need to read deployment descriptors or set up internal resources.
>>> The ServletExtension already has a reference to the ServletContext, you can
>>> just pass it in to your factory.
>>>
>>> I guess this is another argument against using the factory, vs just
>>> creating it in the ServletExtension.
>> Unfortunately my unit tests run in junit. I cannot integrate the
>> ServletExtension mechanism which is
>> a wildfly based integration usecase. If PicketLink SAML SSO has to
>> integrate with Undertow, the unit
>> tests have to run in JUnit like we do with Tomcat and Jetty.
>>
>> Do you have goals for Undertow to be a standalone web container (like
>> jetty) or it is just a web container
>> usable in Wildfly?
>>
>>> Stuart
>>>
>>>> Regards,
>>>> Anil
>>>>
>>>> On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
>>>>> How is this authentication mechanism being added?
>>>>>
>>>>> On 16/12/13 15:33, Anil Saldhana wrote:
>>>>>> Hi,
>>>>>>         can the authentication mechanism have a lifecycle based on the
>>>>>> context lifecycle?
>>>>>>
>>>>>> I need access to the ServletContext to look for deployment descriptors
>>>>>> using the servletContext.getResourceAsStream() call.
>>>>>>
>>>>>> I am thinking something along the lines of:
>>>>>>
>>>>>> authenticationMechanism.start(ServletContext);
>>>>>> authenticationMechanis.stop();
>>>>>>
>>>>>> This will give an opportunity for the authentication mechanism to
>>>>>> initialize and finalize any resources.
>>>>>>
>>>>>> Regards,
>>>>>> Anil
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>


From bburke at redhat.com  Tue Dec 17 11:30:20 2013
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Dec 2013 11:30:20 -0500
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52B07137.9090400@redhat.com>
References: <52AF1D41.1070804@redhat.com>
	<52AF1E7B.90705@jboss.com>	<52AF1F2C.5090404@redhat.com>	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
	<52B07137.9090400@redhat.com>
Message-ID: <52B07C1C.8060703@redhat.com>



On 12/17/2013 10:43 AM, Anil Saldhana wrote:
> On 12/17/2013 01:38 AM, Stuart Douglas wrote:
>>
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> To: undertow-dev at lists.jboss.org
>>> Sent: Monday, 16 December, 2013 4:41:32 PM
>>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>>
>>> Right now, I just have a junit test.  I set the auth mechanism factory
>>> in the deployment info.
>>>
>>> di.addAuthenticationMechanism("FORM" ,
>>> SPFormAuthenticationMechanism.FACTORY);
>>>
>>> Irrespective of how it is added, when the deployment start happens,
>>> undertow should try to start
>>> the authentication mechanisms by providing a handle to the servlet
>>> context.  The authentication mechanism
>>> may need to read deployment descriptors or set up internal resources.
>> The ServletExtension already has a reference to the ServletContext, you can just pass it in to your factory.
>>
>> I guess this is another argument against using the factory, vs just creating it in the ServletExtension.
> Unfortunately my unit tests run in junit. I cannot integrate the
> ServletExtension mechanism which is
> a wildfly based integration usecase. If PicketLink SAML SSO has to
> integrate with Undertow, the unit
> tests have to run in JUnit like we do with Tomcat and Jetty.
>
> Do you have goals for Undertow to be a standalone web container (like
> jetty) or it is just a web container
> usable in Wildfly?
>

I already use Undertow in unit tests.  I'm also planning on swapping out 
the embedded container we use to test Resteasy in favor of Undertow.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Tue Dec 17 11:43:20 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 17 Dec 2013 10:43:20 -0600
Subject: [undertow-dev] AuthenticationMechanism lifecycle
In-Reply-To: <52B0748E.3030702@redhat.com>
References: <52AF1D41.1070804@redhat.com> <52AF1E7B.90705@jboss.com>
	<52AF1F2C.5090404@redhat.com>
	<2041174427.38346430.1387265912479.JavaMail.root@redhat.com>
	<52B07137.9090400@redhat.com>
	<6544426.38593624.1387295661751.JavaMail.root@redhat.com>
	<52B0748E.3030702@redhat.com>
Message-ID: <52B07F28.5010303@redhat.com>

On 12/17/2013 09:58 AM, Anil Saldhana wrote:
> On 12/17/2013 09:54 AM, Stuart Douglas wrote:
>> ServletExtension is usable in embedded deployments as well now. I recently added io.undertow.servlet.api.DeploymentInfo#addServletExtension, so you can manually add extensions to the deployment as well as discovering them.
> Do you have any unit tests that I can see the usage?
Never mind. Did some authenticationmechanismfactory magic.
>> Stuart
>>
>>
>>
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> To: "Stuart Douglas" <sdouglas at redhat.com>
>>> Cc: undertow-dev at lists.jboss.org
>>> Sent: Tuesday, 17 December, 2013 4:43:51 PM
>>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>>
>>> On 12/17/2013 01:38 AM, Stuart Douglas wrote:
>>>> ----- Original Message -----
>>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>> To: undertow-dev at lists.jboss.org
>>>>> Sent: Monday, 16 December, 2013 4:41:32 PM
>>>>> Subject: Re: [undertow-dev] AuthenticationMechanism lifecycle
>>>>>
>>>>> Right now, I just have a junit test.  I set the auth mechanism factory
>>>>> in the deployment info.
>>>>>
>>>>> di.addAuthenticationMechanism("FORM" ,
>>>>> SPFormAuthenticationMechanism.FACTORY);
>>>>>
>>>>> Irrespective of how it is added, when the deployment start happens,
>>>>> undertow should try to start
>>>>> the authentication mechanisms by providing a handle to the servlet
>>>>> context.  The authentication mechanism
>>>>> may need to read deployment descriptors or set up internal resources.
>>>> The ServletExtension already has a reference to the ServletContext, you can
>>>> just pass it in to your factory.
>>>>
>>>> I guess this is another argument against using the factory, vs just
>>>> creating it in the ServletExtension.
>>> Unfortunately my unit tests run in junit. I cannot integrate the
>>> ServletExtension mechanism which is
>>> a wildfly based integration usecase. If PicketLink SAML SSO has to
>>> integrate with Undertow, the unit
>>> tests have to run in JUnit like we do with Tomcat and Jetty.
>>>
>>> Do you have goals for Undertow to be a standalone web container (like
>>> jetty) or it is just a web container
>>> usable in Wildfly?
>>>
>>>> Stuart
>>>>
>>>>> Regards,
>>>>> Anil
>>>>>
>>>>> On 12/16/2013 09:38 AM, Darran Lofthouse wrote:
>>>>>> How is this authentication mechanism being added?
>>>>>>
>>>>>> On 16/12/13 15:33, Anil Saldhana wrote:
>>>>>>> Hi,
>>>>>>>          can the authentication mechanism have a lifecycle based on the
>>>>>>> context lifecycle?
>>>>>>>
>>>>>>> I need access to the ServletContext to look for deployment descriptors
>>>>>>> using the servletContext.getResourceAsStream() call.
>>>>>>>
>>>>>>> I am thinking something along the lines of:
>>>>>>>
>>>>>>> authenticationMechanism.start(ServletContext);
>>>>>>> authenticationMechanis.stop();
>>>>>>>
>>>>>>> This will give an opportunity for the authentication mechanism to
>>>>>>> initialize and finalize any resources.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anil
>>>>>>>


From bburke at redhat.com  Tue Dec 17 12:12:43 2013
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Dec 2013 12:12:43 -0500
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <213723608.38345203.1387265721472.JavaMail.root@redhat.com>
References: <52AA3468.9020609@redhat.com> <52AB22CC.8030104@redhat.com>
	<160D3CB9-3136-4DE6-9C82-8F3A07E66A1D@redhat.com>
	<52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
	<52AB955C.3030602@redhat.com>
	<1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
	<52AF03A8.8070109@redhat.com>
	<213723608.38345203.1387265721472.JavaMail.root@redhat.com>
Message-ID: <52B0860B.7030108@redhat.com>



On 12/17/2013 2:35 AM, Stuart Douglas wrote:
>
>>
>> On 12/14/2013 5:33 AM, Stuart Douglas wrote:
>>>
>>>> What does ordering have to do with AuthMechFactory?  Are you planning an
>>>> additional META-INF/services mechanism for AuthMechFactorys?  If not,
>>>> how does one plug in one?  Via a ServletExtension?  If so, *AGAIN*, what
>>>> is the point of the AuthMechFactory when all the construction can be
>>>> done within the ServletExtension?
>>>
>>> Because you can have multiple servlet extensions. This way undertow
>>> controls the order. If both extensions just add themselves you have no
>>> defined order.
>>>
>>
>> Again, what does ordering have to do with requiring an AuthMechFactory
>> interface?
>>
>> MyServletExtension {
>>      di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
>> }
>>
>> Why do i need a AuthMechFactory if the servlet extension is able to
>> construct the AuthMech?  I just would never use AuthMechFactory as all
>> config information is already available within the ServletExtension for
>> me to construct the AuthMechanism.  In fact, there's much more metadata
>> available within the ServletExtension than is passed to the AuthMechFactory.
>
> Note that with my latest changes you can do exactly what you mention above (di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));).
>
> I guess the only real thing it buys you is having the ability to configure the same mechanism with different properties, although I am not sure
> if that is really something that anyone would ever want to do.
>
> It also makes reading the config properties easier, as they are passed directly to the factory, although I guess it is pretty easy to just retrieve them directly, especially if I just add a convenience method.
>
> So maybe it is not really worth having the factory concept, although given that you don't have to use it if you don't want to I am not sure if we should keep it or not.
>

BTW, all in all, the AuthMech SPI is holding up pretty well.  Good stuff.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Tue Dec 17 16:50:19 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Tue, 17 Dec 2013 15:50:19 -0600
Subject: [undertow-dev] Form Authentication : Save/Restore Request
In-Reply-To: <1251685034.33998045.1386580875542.JavaMail.root@redhat.com>
References: <529E471F.4040308@redhat.com> <529E47CD.6080009@redhat.com>
	<1251685034.33998045.1386580875542.JavaMail.root@redhat.com>
Message-ID: <52B0C71B.9040604@redhat.com>

On 12/09/2013 03:21 AM, Stuart Douglas wrote:
> This still needs to be implemented: https://issues.jboss.org/browse/UNDERTOW-156
>
> I should get to it some time this week.
Do you know if you handled GET requests or just POST?
 From my testing, it looks  like the request params via GET are not 
being put back (after the FORM authentication workflow).
>
> Stuart
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Tuesday, 3 December, 2013 10:06:21 PM
>> Subject: Re: [undertow-dev] Form Authentication : Save/Restore Request
>>
>> Sometime ago, I did write the form auth code in a generic library
>> https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/HTTPFormAuthentication.java
>> https://github.com/picketbox/picketbox/blob/master/http/src/main/java/org/picketbox/http/authentication/AbstractHTTPAuthentication.java
>>
>> This does request caching.
>>
>> On 12/03/2013 03:03 PM, Anil Saldhana wrote:
>>> Hi,
>>>      looking at the FormAuthenticationMechanism code, I cannot figure out
>>> whether the original request gets cached (saved) before redirecting to
>>> the form login page. After authentication, it needs to be restored back.
>>> This is the only way in which the original post data to a secured URL
>>> can be saved after the form authentication work flow.
>>>
>>> Regards,
>>> Anil

From sdouglas at redhat.com  Wed Dec 18 03:00:40 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 18 Dec 2013 03:00:40 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanismFactory
In-Reply-To: <52B0860B.7030108@redhat.com>
References: <52AA3468.9020609@redhat.com> <52AB5318.5070106@redhat.com>
	<2140061942.37251129.1386968526231.JavaMail.root@redhat.com>
	<52AB955C.3030602@redhat.com>
	<1816266112.37318097.1387017200025.JavaMail.root@redhat.com>
	<52AF03A8.8070109@redhat.com>
	<213723608.38345203.1387265721472.JavaMail.root@redhat.com>
	<52B0860B.7030108@redhat.com>
Message-ID: <1286213162.38956538.1387353640595.JavaMail.root@redhat.com>


> >
> 
> BTW, all in all, the AuthMech SPI is holding up pretty well.  Good stuff.
> 
> Bill

Thanks. It is good to finally get some feedback on all this stuff.

Stuart

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From Anil.Saldhana at redhat.com  Thu Dec 19 12:02:15 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 11:02:15 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
Message-ID: <52B32697.9050501@redhat.com>

Stuart,
   I am unsure it is right to use cookies to remember the form redirect 
url.  Traditionally, web containers (Tomcat and Jetty) have used http 
session to remember the redirect url.

If an user has turned off cookies, then it may not work.

Regards,
Anil

From darran.lofthouse at jboss.com  Thu Dec 19 12:13:32 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 19 Dec 2013 17:13:32 +0000
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52AF2923.1080301@redhat.com>
References: <52AF1FCB.60904@redhat.com> <52AF23E9.40700@jboss.com>
	<52AF2923.1080301@redhat.com>
Message-ID: <52B3293C.2010409@jboss.com>

Coming back to this topic ;-)

The reasons I believe it is the authenticate method that should signal a 
mechanism wants exclusivity in sending a challenge are: -

1 - This method already returns one of three values to indicate it's 
authentication state, adding one more value to indicate that a mechanism 
has started authentication but wants exclusivity would fit with this.

2 - The mechanism doesn't need to be first just to be able to request 
exclusivity - also not going to cause a complication if another 
mechanism had added it's challenge as that would not be able to happen.

3 - In general we should try and avoid writing mechanism that only work 
alone (depending on various constraints), having a sendChallenge that 
always requested exclusivity would go against this - whereas a mechanism 
detecting it wants exclusivity in the authenticate stage would be valid 
as remaining mechanisms would still be usable for the times it does not 
request exclusivity.

Regards,
Darran Lofthouse.


On 16/12/13 16:24, Bill Burke wrote:
> FYI: For my case at least, I can co-exist with other Auth mechanisms, I
> just need to be able to abort the sendChallenge loop and make sure I can
> have my auth mechanism first in the sendChallenge loop (pretty sure that
> one is already there).
>
> On 12/16/2013 11:01 AM, Darran Lofthouse wrote:
>> This may come under the same area as the single challenge I just replied
>> to Bill about.
>>
>> For mechanisms that may behave in this way can we detect that they would
>> want exclusivity from within the authenticate method?
>>
>> On 16/12/13 15:44, Anil Saldhana wrote:
>>> Hi,
>>>      I am wondering if a flag can be set in ChallengeResult such that
>>> undertow does not try to set the response code on the httpserverexchange
>>> before sending the challenge?
>>>
>>> The reason is that an authentication mechanism may have already utilized
>>> the httpservletresponse object to set a response code such as:
>>>
>>> ===========
>>> response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
>>> response.sendRedirect(destination);
>>> ==============
>>>
>>> Now since undertow tries to set a response code on the
>>> httpServerExchange, there is an error.
>>>
>>> Regards,
>>> Anil
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>

From Anil.Saldhana at redhat.com  Thu Dec 19 12:24:11 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 11:24:11 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B32697.9050501@redhat.com>
References: <52B32697.9050501@redhat.com>
Message-ID: <52B32BBB.1070906@redhat.com>

Also no path is being set on the cookie. If user is using more than one 
web app with FORM authentication
on the same server, this may wreck havoc.

On 12/19/2013 11:02 AM, Anil Saldhana wrote:
> Stuart,
>     I am unsure it is right to use cookies to remember the form redirect
> url.  Traditionally, web containers (Tomcat and Jetty) have used http
> session to remember the redirect url.
>
> If an user has turned off cookies, then it may not work.
>
> Regards,
> Anil

From Anil.Saldhana at redhat.com  Thu Dec 19 12:27:47 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 11:27:47 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B32BBB.1070906@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
Message-ID: <52B32C93.4000308@redhat.com>

Thinking further, this may inhibit a case of cookie injection that hacks 
the location url.
After form authentication, the server blindly redirects to the location 
read from the cookie.

On 12/19/2013 11:24 AM, Anil Saldhana wrote:
> Also no path is being set on the cookie. If user is using more than one
> web app with FORM authentication
> on the same server, this may wreck havoc.
>
> On 12/19/2013 11:02 AM, Anil Saldhana wrote:
>> Stuart,
>>      I am unsure it is right to use cookies to remember the form redirect
>> url.  Traditionally, web containers (Tomcat and Jetty) have used http
>> session to remember the redirect url.
>>
>> If an user has turned off cookies, then it may not work.
>>
>> Regards,
>> Anil
>


From Anil.Saldhana at redhat.com  Thu Dec 19 12:30:41 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 11:30:41 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B32C93.4000308@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
	<52B32C93.4000308@redhat.com>
Message-ID: <52B32D41.7090603@redhat.com>

Probably not going to happen. Just use httpsession. :)

On 12/19/2013 11:27 AM, Anil Saldhana wrote:
> Thinking further, this may inhibit a case of cookie injection that hacks
> the location url.
> After form authentication, the server blindly redirects to the location
> read from the cookie.
>
> On 12/19/2013 11:24 AM, Anil Saldhana wrote:
>> >Also no path is being set on the cookie. If user is using more than one
>> >web app with FORM authentication
>> >on the same server, this may wreck havoc.
>> >
>> >On 12/19/2013 11:02 AM, Anil Saldhana wrote:
>>> >>Stuart,
>>> >>      I am unsure it is right to use cookies to remember the form redirect
>>> >>url.  Traditionally, web containers (Tomcat and Jetty) have used http
>>> >>session to remember the redirect url.
>>> >>
>>> >>If an user has turned off cookies, then it may not work.
>>> >>
>>> >>Regards,
>>> >>Anil
>> >


From Anil.Saldhana at redhat.com  Thu Dec 19 12:44:49 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 11:44:49 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B32D41.7090603@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
	<52B32C93.4000308@redhat.com> <52B32D41.7090603@redhat.com>
Message-ID: <52B33091.7080406@redhat.com>

Scratch what I just said.

FormAuthentication.java uses cookies while 
ServletFormAuthentication.java uses session.

I think the reason is that the former has no facility for Servlet 
httpSession.

On 12/19/2013 11:30 AM, Anil Saldhana wrote:
> Probably not going to happen. Just use httpsession. :)
>
> On 12/19/2013 11:27 AM, Anil Saldhana wrote:
>> Thinking further, this may inhibit a case of cookie injection that hacks
>> the location url.
>> After form authentication, the server blindly redirects to the location
>> read from the cookie.
>>
>> On 12/19/2013 11:24 AM, Anil Saldhana wrote:
>>>> Also no path is being set on the cookie. If user is using more than one
>>>> web app with FORM authentication
>>>> on the same server, this may wreck havoc.
>>>>
>>>> On 12/19/2013 11:02 AM, Anil Saldhana wrote:
>>>>>> Stuart,
>>>>>>       I am unsure it is right to use cookies to remember the form redirect
>>>>>> url.  Traditionally, web containers (Tomcat and Jetty) have used http
>>>>>> session to remember the redirect url.
>>>>>>
>>>>>> If an user has turned off cookies, then it may not work.
>>>>>>
>>>>>> Regards,
>>>>>> Anil
>>>>

From jason.greene at redhat.com  Thu Dec 19 13:02:07 2013
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 19 Dec 2013 12:02:07 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B33091.7080406@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
	<52B32C93.4000308@redhat.com> <52B32D41.7090603@redhat.com>
	<52B33091.7080406@redhat.com>
Message-ID: <22FA7EA8-D9EC-468A-8C28-7AF45DDE99AA@redhat.com>

Can you even use the web these days without cookies :)

On Dec 19, 2013, at 11:44 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Scratch what I just said.
> 
> FormAuthentication.java uses cookies while 
> ServletFormAuthentication.java uses session.
> 
> I think the reason is that the former has no facility for Servlet 
> httpSession.
> 
> On 12/19/2013 11:30 AM, Anil Saldhana wrote:
>> Probably not going to happen. Just use httpsession. :)
>> 
>> On 12/19/2013 11:27 AM, Anil Saldhana wrote:
>>> Thinking further, this may inhibit a case of cookie injection that hacks
>>> the location url.
>>> After form authentication, the server blindly redirects to the location
>>> read from the cookie.
>>> 
>>> On 12/19/2013 11:24 AM, Anil Saldhana wrote:
>>>>> Also no path is being set on the cookie. If user is using more than one
>>>>> web app with FORM authentication
>>>>> on the same server, this may wreck havoc.
>>>>> 
>>>>> On 12/19/2013 11:02 AM, Anil Saldhana wrote:
>>>>>>> Stuart,
>>>>>>>      I am unsure it is right to use cookies to remember the form redirect
>>>>>>> url.  Traditionally, web containers (Tomcat and Jetty) have used http
>>>>>>> session to remember the redirect url.
>>>>>>> 
>>>>>>> If an user has turned off cookies, then it may not work.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Anil
>>>>> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From Anil.Saldhana at redhat.com  Thu Dec 19 14:30:30 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 13:30:30 -0600
Subject: [undertow-dev] PicketLink SAML SSO Usecase running with Undertow in
	JUnit
Message-ID: <52B34956.3000500@redhat.com>

Finally saw success today with
https://github.com/anilsaldhana/picketlink-bindings/blob/undertow/picketlink-wildfly-common/src/test/java/org/picketlink/test/identity/federation/bindings/wildfly/SPInitiatedSSOWorkflowTestCase.java

Some relevant code is
https://github.com/anilsaldhana/picketlink-bindings/blob/undertow/picketlink-wildfly-common/src/main/java/org/picketlink/identity/federation/bindings/wildfly/sp/SPFormAuthenticationMechanism.java
https://github.com/anilsaldhana/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/filters/IDPFilter.java

Please pardon the dust.

From Anil.Saldhana at redhat.com  Thu Dec 19 16:59:26 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Thu, 19 Dec 2013 15:59:26 -0600
Subject: [undertow-dev] PicketLink SAML SSO Usecase running with
 Undertow in JUnit
In-Reply-To: <52B34956.3000500@redhat.com>
References: <52B34956.3000500@redhat.com>
Message-ID: <52B36C3E.9000505@redhat.com>

I want to add that this JUnit testcase uses Undertow as an embeddable 
web container. I make use of the Undertow API (Builder/DeploymentInfo).

Next step for me would be to utilize the ServletExtension feature of 
Undertow and get things working in WildFly for PicketLink SAML SSO.

On 12/19/2013 01:30 PM, Anil Saldhana wrote:
> Finally saw success today with
> https://github.com/anilsaldhana/picketlink-bindings/blob/undertow/picketlink-wildfly-common/src/test/java/org/picketlink/test/identity/federation/bindings/wildfly/SPInitiatedSSOWorkflowTestCase.java
>
> Some relevant code is
> https://github.com/anilsaldhana/picketlink-bindings/blob/undertow/picketlink-wildfly-common/src/main/java/org/picketlink/identity/federation/bindings/wildfly/sp/SPFormAuthenticationMechanism.java
> https://github.com/anilsaldhana/picketlink/blob/master/modules/federation/src/main/java/org/picketlink/identity/federation/web/filters/IDPFilter.java
>
> Please pardon the dust.
>


From bburke at redhat.com  Thu Dec 19 19:12:54 2013
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Dec 2013 19:12:54 -0500
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52B3293C.2010409@jboss.com>
References: <52AF1FCB.60904@redhat.com>
	<52AF23E9.40700@jboss.com>	<52AF2923.1080301@redhat.com>
	<52B3293C.2010409@jboss.com>
Message-ID: <52B38B86.4050908@redhat.com>


On 12/19/2013 12:13 PM, Darran Lofthouse wrote:
> Coming back to this topic ;-)
>
> The reasons I believe it is the authenticate method that should signal a
> mechanism wants exclusivity in sending a challenge are: -
>
> 1 - This method already returns one of three values to indicate it's
> authentication state, adding one more value to indicate that a mechanism
> has started authentication but wants exclusivity would fit with this.
>
> 2 - The mechanism doesn't need to be first just to be able to request
> exclusivity - also not going to cause a complication if another
> mechanism had added it's challenge as that would not be able to happen.
>
> 3 - In general we should try and avoid writing mechanism that only work
> alone (depending on various constraints), having a sendChallenge that
> always requested exclusivity would go against this - whereas a mechanism
> detecting it wants exclusivity in the authenticate stage would be valid
> as remaining mechanisms would still be usable for the times it does not
> request exclusivity.
>

#3 just doesn't work for me.

I have two mechanisms for keycloak:

A) Bearer token mechanism that uses the Authorization header and 
challenges with a 401 and WWW-Authenticate
B) OAuth browser redirection mechanism, that challenges with a 302 and a 
Location header.  This is a redirect to the authentication server where 
it will display a login form.

Mechanism (B) will not ever request exclusivity during the authenticate 
phase because keycloak also allows for (A) in the same deployment. 
Mechanism (B) will not ever be able to challenge if it can't set a 302 
response code.  I worry that if other mechanisms add WWW-Authenticate 
headers to a 302 response, it may confuse the user-agent, but this worry 
might be bogus.

So, I don't agree with #3's statement that "having sendChallenge that 
always requested exclusivity would go against this".  Mechanism (B) 
works with a other mechanisms as long as the user-agent is doing 
preemptive authentication.

Whether Keycloak is successful or not is besides the point.  The use 
case where an auth mechanism needs to redirect to another machine to 
display a login form is a valid one.


Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sdouglas at redhat.com  Fri Dec 20 05:36:21 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 20 Dec 2013 05:36:21 -0500 (EST)
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <52B33091.7080406@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
	<52B32C93.4000308@redhat.com> <52B32D41.7090603@redhat.com>
	<52B33091.7080406@redhat.com>
Message-ID: <1011706036.40276922.1387535781325.JavaMail.root@redhat.com>



----- Original Message -----
> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 19 December, 2013 6:44:49 PM
> Subject: Re: [undertow-dev] FormAuthentication -> handleRedirectback method
> 
> Scratch what I just said.
> 
> FormAuthentication.java uses cookies while
> ServletFormAuthentication.java uses session.
> 
> I think the reason is that the former has no facility for Servlet
> httpSession.
> 

I will change the non-servlet one to also use the session. 

Stuart

> On 12/19/2013 11:30 AM, Anil Saldhana wrote:
> > Probably not going to happen. Just use httpsession. :)
> >
> > On 12/19/2013 11:27 AM, Anil Saldhana wrote:
> >> Thinking further, this may inhibit a case of cookie injection that hacks
> >> the location url.
> >> After form authentication, the server blindly redirects to the location
> >> read from the cookie.
> >>
> >> On 12/19/2013 11:24 AM, Anil Saldhana wrote:
> >>>> Also no path is being set on the cookie. If user is using more than one
> >>>> web app with FORM authentication
> >>>> on the same server, this may wreck havoc.
> >>>>
> >>>> On 12/19/2013 11:02 AM, Anil Saldhana wrote:
> >>>>>> Stuart,
> >>>>>>       I am unsure it is right to use cookies to remember the form
> >>>>>>       redirect
> >>>>>> url.  Traditionally, web containers (Tomcat and Jetty) have used http
> >>>>>> session to remember the redirect url.
> >>>>>>
> >>>>>> If an user has turned off cookies, then it may not work.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Anil
> >>>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From darran.lofthouse at jboss.com  Fri Dec 20 05:44:51 2013
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 20 Dec 2013 10:44:51 +0000
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52B38B86.4050908@redhat.com>
References: <52AF1FCB.60904@redhat.com>	<52AF23E9.40700@jboss.com>	<52AF2923.1080301@redhat.com>	<52B3293C.2010409@jboss.com>
	<52B38B86.4050908@redhat.com>
Message-ID: <52B41FA3.8010609@jboss.com>

Thanks for the clarification Bill.

So in your case we know in advance that there is a single mechanism 
which should be the only mechanism sending challenges and at least one 
more mechanism that can perform the authentication without the need to 
send challenges.

I am just wondering for this scenario if we can handle this better 
during registration of the mechanisms rather than at runtime processing 
a request.

Regards,
Darran Lofthouse.


On 20/12/13 00:12, Bill Burke wrote:
>
> On 12/19/2013 12:13 PM, Darran Lofthouse wrote:
>> Coming back to this topic ;-)
>>
>> The reasons I believe it is the authenticate method that should signal a
>> mechanism wants exclusivity in sending a challenge are: -
>>
>> 1 - This method already returns one of three values to indicate it's
>> authentication state, adding one more value to indicate that a mechanism
>> has started authentication but wants exclusivity would fit with this.
>>
>> 2 - The mechanism doesn't need to be first just to be able to request
>> exclusivity - also not going to cause a complication if another
>> mechanism had added it's challenge as that would not be able to happen.
>>
>> 3 - In general we should try and avoid writing mechanism that only work
>> alone (depending on various constraints), having a sendChallenge that
>> always requested exclusivity would go against this - whereas a mechanism
>> detecting it wants exclusivity in the authenticate stage would be valid
>> as remaining mechanisms would still be usable for the times it does not
>> request exclusivity.
>>
>
> #3 just doesn't work for me.
>
> I have two mechanisms for keycloak:
>
> A) Bearer token mechanism that uses the Authorization header and
> challenges with a 401 and WWW-Authenticate
> B) OAuth browser redirection mechanism, that challenges with a 302 and a
> Location header.  This is a redirect to the authentication server where
> it will display a login form.
>
> Mechanism (B) will not ever request exclusivity during the authenticate
> phase because keycloak also allows for (A) in the same deployment.
> Mechanism (B) will not ever be able to challenge if it can't set a 302
> response code.  I worry that if other mechanisms add WWW-Authenticate
> headers to a 302 response, it may confuse the user-agent, but this worry
> might be bogus.
>
> So, I don't agree with #3's statement that "having sendChallenge that
> always requested exclusivity would go against this".  Mechanism (B)
> works with a other mechanisms as long as the user-agent is doing
> preemptive authentication.
>
> Whether Keycloak is successful or not is besides the point.  The use
> case where an auth mechanism needs to redirect to another machine to
> display a login form is a valid one.
>
>
> Bill
>

From sdouglas at redhat.com  Fri Dec 20 08:34:35 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 20 Dec 2013 08:34:35 -0500 (EST)
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52B38B86.4050908@redhat.com>
References: <52AF1FCB.60904@redhat.com> <52AF23E9.40700@jboss.com>
	<52AF2923.1080301@redhat.com> <52B3293C.2010409@jboss.com>
	<52B38B86.4050908@redhat.com>
Message-ID: <35261935.40328492.1387546475254.JavaMail.root@redhat.com>


> >
> > 3 - In general we should try and avoid writing mechanism that only work
> > alone (depending on various constraints), having a sendChallenge that
> > always requested exclusivity would go against this - whereas a mechanism
> > detecting it wants exclusivity in the authenticate stage would be valid
> > as remaining mechanisms would still be usable for the times it does not
> > request exclusivity.
> >
> 
> #3 just doesn't work for me.
> 
> I have two mechanisms for keycloak:
> 
> A) Bearer token mechanism that uses the Authorization header and
> challenges with a 401 and WWW-Authenticate
> B) OAuth browser redirection mechanism, that challenges with a 302 and a
> Location header.  This is a redirect to the authentication server where
> it will display a login form.
> 
> Mechanism (B) will not ever request exclusivity during the authenticate
> phase because keycloak also allows for (A) in the same deployment.
> Mechanism (B) will not ever be able to challenge if it can't set a 302
> response code.  I worry that if other mechanisms add WWW-Authenticate
> headers to a 302 response, it may confuse the user-agent, but this worry
> might be bogus.
> 
> So, I don't agree with #3's statement that "having sendChallenge that
> always requested exclusivity would go against this".  Mechanism (B)
> works with a other mechanisms as long as the user-agent is doing
> preemptive authentication.
> 
> Whether Keycloak is successful or not is besides the point.  The use
> case where an auth mechanism needs to redirect to another machine to
> display a login form is a valid one.

So basically you want a way to end the process from the sendChallenge() method?

If so you can basically already doing this by just invoking the HttpServerExchange.endEchange() method 

This is not handled super well at the moment though, as the other mechanisms will still be tried, they just cant do anything as the response has been committed. We should do something about this.  

Stuart

> 
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

From bburke at redhat.com  Fri Dec 20 09:34:39 2013
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Dec 2013 09:34:39 -0500
Subject: [undertow-dev] AuthenticationMechanism,
 ChallengeResult and Response Code
In-Reply-To: <52B41FA3.8010609@jboss.com>
References: <52AF1FCB.60904@redhat.com>	<52AF23E9.40700@jboss.com>	<52AF2923.1080301@redhat.com>	<52B3293C.2010409@jboss.com>	<52B38B86.4050908@redhat.com>
	<52B41FA3.8010609@jboss.com>
Message-ID: <52B4557F.4080403@redhat.com>



On 12/20/2013 5:44 AM, Darran Lofthouse wrote:
> Thanks for the clarification Bill.
>
> So in your case we know in advance that there is a single mechanism
> which should be the only mechanism sending challenges and at least one
> more mechanism that can perform the authentication without the need to
> send challenges.
>
> I am just wondering for this scenario if we can handle this better
> during registration of the mechanisms rather than at runtime processing
> a request.
>

If an OAUTH or OpenID mechanism could be guarenteed to be last to 
authenticate(), then these mechanisms could pass back a 
NOT_AUTHENTICATED instead of a NOT_ATTEMPTED and perform the redirect 
within authenticate()...

OR

If OATH/OpenID could be guaranteed to be first to sendChallenge, then it 
could end the exchange as Stuart suggested.

Another thing that might work is if the exchange could be "rolled back". 
  Then the OAUTH/OpenID could rollback any changes made in other 
sendChallenge() requests and end() the exchange.  Order wouldn't matter 
then.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From Anil.Saldhana at redhat.com  Fri Dec 20 16:04:21 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Fri, 20 Dec 2013 15:04:21 -0600
Subject: [undertow-dev] FormAuthentication -> handleRedirectback method
In-Reply-To: <1011706036.40276922.1387535781325.JavaMail.root@redhat.com>
References: <52B32697.9050501@redhat.com> <52B32BBB.1070906@redhat.com>
	<52B32C93.4000308@redhat.com> <52B32D41.7090603@redhat.com>
	<52B33091.7080406@redhat.com>
	<1011706036.40276922.1387535781325.JavaMail.root@redhat.com>
Message-ID: <52B4B0D5.5020405@redhat.com>

On 12/20/2013 04:36 AM, Stuart Douglas wrote:
>
> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Thursday, 19 December, 2013 6:44:49 PM
>> Subject: Re: [undertow-dev] FormAuthentication -> handleRedirectback method
>>
>> Scratch what I just said.
>>
>> FormAuthentication.java uses cookies while
>> ServletFormAuthentication.java uses session.
>>
>> I think the reason is that the former has no facility for Servlet
>> httpSession.
>>
> I will change the non-servlet one to also use the session.
>
I am unsure if you want to provide the form authentication feature to 
non-servlet based use cases.  I
don't think it really is used in HTTP based services  - DIGEST,BASIC and 
CLIENT-CERT are more prominent in non-servlet based use cases.
>
>> On 12/19/2013 11:30 AM, Anil Saldhana wrote:
>>> Probably not going to happen. Just use httpsession. :)
>>>
>>> On 12/19/2013 11:27 AM, Anil Saldhana wrote:
>>>> Thinking further, this may inhibit a case of cookie injection that hacks
>>>> the location url.
>>>> After form authentication, the server blindly redirects to the location
>>>> read from the cookie.
>>>>
>>>> On 12/19/2013 11:24 AM, Anil Saldhana wrote:
>>>>>> Also no path is being set on the cookie. If user is using more than one
>>>>>> web app with FORM authentication
>>>>>> on the same server, this may wreck havoc.
>>>>>>
>>>>>> On 12/19/2013 11:02 AM, Anil Saldhana wrote:
>>>>>>>> Stuart,
>>>>>>>>        I am unsure it is right to use cookies to remember the form
>>>>>>>>        redirect
>>>>>>>> url.  Traditionally, web containers (Tomcat and Jetty) have used http
>>>>>>>> session to remember the redirect url.
>>>>>>>>
>>>>>>>> If an user has turned off cookies, then it may not work.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Anil
>>>>>>

From shanloid at gmail.com  Sun Dec 22 23:39:47 2013
From: shanloid at gmail.com (Shannon Lloyd)
Date: Mon, 23 Dec 2013 14:39:47 +1000
Subject: [undertow-dev] Should AttachmentKey implement equals?
Message-ID: <CAHAPd=CjGUAEove-zSUrr5NoSntj5FnzxsRf7ukfSrJ3RMqpYg@mail.gmail.com>

Hi,

I'm noticing that I can't pull an attachment back off the exchange using
AttachmentKey.create(Class), presumably because AttachmentKey (or rather
SimpleAttachmentKey) doesn't override equals to compare based on the
wrapped Class object, so it's using object identity, which obviously
doesn't work.

Is this by design? Do I need to hold onto the key I used to add the
attachment in the first place? This seems a bit counter-intuitive, as it
means pushing keys around between handlers, when simply implementing equals
on the key would avoid that. Am I supposed to provide my own key
implementation (i.e basically rewrite SimpleAttachment key - I can't
believe that this is the answer)?

Or am I just missing something obvious?

Cheers,
Shannon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20131223/237255c7/attachment-0001.html 

From sdouglas at redhat.com  Mon Dec 23 04:42:47 2013
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 23 Dec 2013 04:42:47 -0500 (EST)
Subject: [undertow-dev] Should AttachmentKey implement equals?
In-Reply-To: <CAHAPd=CjGUAEove-zSUrr5NoSntj5FnzxsRf7ukfSrJ3RMqpYg@mail.gmail.com>
References: <CAHAPd=CjGUAEove-zSUrr5NoSntj5FnzxsRf7ukfSrJ3RMqpYg@mail.gmail.com>
Message-ID: <1583019874.40874975.1387791767675.JavaMail.root@redhat.com>

This is by design. The map that holds the keys is an identity hash map.

If we just did equality based on the class then it would be impossible to have two different attachments of the same type, which although not super common does occur.

There is no real need to pass the keys around, just make them a static final field somewhere. 

Stuart

----- Original Message -----
> From: "Shannon Lloyd" <shanloid at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Monday, 23 December, 2013 5:39:47 AM
> Subject: [undertow-dev] Should AttachmentKey implement equals?
> 
> Hi,
> 
> I'm noticing that I can't pull an attachment back off the exchange using
> AttachmentKey.create(Class), presumably because AttachmentKey (or rather
> SimpleAttachmentKey) doesn't override equals to compare based on the wrapped
> Class object, so it's using object identity, which obviously doesn't work.
> 
> Is this by design? Do I need to hold onto the key I used to add the
> attachment in the first place? This seems a bit counter-intuitive, as it
> means pushing keys around between handlers, when simply implementing equals
> on the key would avoid that. Am I supposed to provide my own key
> implementation (i.e basically rewrite SimpleAttachment key - I can't believe
> that this is the answer)?
> 
> Or am I just missing something obvious?
> 
> Cheers,
> Shannon
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From Anil.Saldhana at redhat.com  Mon Dec 23 11:31:10 2013
From: Anil.Saldhana at redhat.com (Anil Saldhana)
Date: Mon, 23 Dec 2013 10:31:10 -0600
Subject: [undertow-dev] Should AttachmentKey implement equals?
In-Reply-To: <1583019874.40874975.1387791767675.JavaMail.root@redhat.com>
References: <CAHAPd=CjGUAEove-zSUrr5NoSntj5FnzxsRf7ukfSrJ3RMqpYg@mail.gmail.com>
	<1583019874.40874975.1387791767675.JavaMail.root@redhat.com>
Message-ID: <52B8654E.8050105@redhat.com>

On 12/23/2013 03:42 AM, Stuart Douglas wrote:
> This is by design. The map that holds the keys is an identity hash map.
>
> If we just did equality based on the class then it would be impossible to have two different attachments of the same type, which although not super common does occur.
Would placing this comment in the Javadoc of the class be useful?

> There is no real need to pass the keys around, just make them a static final field somewhere.
>
> Stuart
>
> ----- Original Message -----
>> From: "Shannon Lloyd" <shanloid at gmail.com>
>> To: undertow-dev at lists.jboss.org
>> Sent: Monday, 23 December, 2013 5:39:47 AM
>> Subject: [undertow-dev] Should AttachmentKey implement equals?
>>
>> Hi,
>>
>> I'm noticing that I can't pull an attachment back off the exchange using
>> AttachmentKey.create(Class), presumably because AttachmentKey (or rather
>> SimpleAttachmentKey) doesn't override equals to compare based on the wrapped
>> Class object, so it's using object identity, which obviously doesn't work.
>>
>> Is this by design? Do I need to hold onto the key I used to add the
>> attachment in the first place? This seems a bit counter-intuitive, as it
>> means pushing keys around between handlers, when simply implementing equals
>> on the key would avoid that. Am I supposed to provide my own key
>> implementation (i.e basically rewrite SimpleAttachment key - I can't believe
>> that this is the answer)?
>>
>> Or am I just missing something obvious?
>>
>> Cheers,
>> Shannon
>>