From rsvoboda at redhat.com  Thu Oct  1 08:17:05 2015
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Thu, 1 Oct 2015 08:17:05 -0400 (EDT)
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP6YmYsbWm4CvM0sLXBaLgkUdvC8XxUR7u18bWPAT6_1JA@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
	<CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
	<CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>
	<CAMquZP6YmYsbWm4CvM0sLXBaLgkUdvC8XxUR7u18bWPAT6_1JA@mail.gmail.com>
Message-ID: <1058932853.21318065.1443701825792.JavaMail.zimbra@redhat.com>

> Right this is my concern. The behavior is different as the bash
> scripts don't exit. They wait for the process to end. Maybe it's
> correct to be different, I don't know.

If you send signal 10 (kill -l 10 returns USR1) AS got restarted thanks while loop - https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/bin/standalone.sh#L299
and it doesn't matter if you execute it normally or with LAUNCH_JBOSS_IN_BACKGROUND

don't know what the real use case is to get it restarted
wildfly-init-redhat.sh and wildfly-init-debian.sh do restart by stop&&start
  	restart)
		$0 stop
		$0 start
EAP 6.4.3 RPM init.d script does stop&&start too
  restart|reload)
      stop
      sleep 3
      start
      RETVAL=$?
      ;;

There is some magic in the .sh scripts with number 128 and it's related wait command / bash / signals
  http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html#sect_12_02_02
  http://veithen.github.io/2014/11/16/sigterm-propagation.html

> 
> Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much
> implemented
> to satisfy the init.d script we have and is not really useful if you run it
> directly.

it is used in: 
  https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-redhat.sh
  https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-debian.sh

read kpid < $JBOSS_PIDFILE in stop function

> If that is really so, I am not a fan of having that in standalone.sh
> directly...
> 

domain.sh has the same mechanism LAUNCH_JBOSS_IN_BACKGROUND + JBOSS_PIDFILE
If it's removed from both files something will have to be added to the init/systemd scripts.

Cheers.
Rostislav

From manderse at redhat.com  Thu Oct  1 08:31:16 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 01 Oct 2015 14:31:16 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560BDF00.90106@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
	<263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
	<560BC9BF.5000200@redhat.com>
	<CAMquZP50rhZ9a76_ov=Eh=fEvsuKdv4Uc+K3RD1wnPnYLwqecA@mail.gmail.com>
	<560BDF00.90106@redhat.com>
Message-ID: <A610F01C-CFFE-4D9B-81F9-33BF2F49C899@redhat.com>

On 30 Sep 2015, at 15:09, Emmanuel Hugonnet wrote:

> Yes ;)
> Well I don't test much on Windows but it works just nice on Linux ;-)

okey, so that explain why you like the scripts - these issues manifests 
itself most on windows ;)

so how do you handle running two servers ? it kills all of them ?

got a link to the exact code you use ?

/max

>
>
> Le 30/09/2015 15:05, Toma? Cerar a ?crit :
>>
>> On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet 
>> <ehugonne at redhat.com <mailto:ehugonne at redhat.com>> wrote:
>>
>>  To stop the process : first I try the management API command then I 
>> have some funky code from arquillian (iirc) which kills the
>>  jboss-modules processes.
>>
>>
>>
>> you probably mean
>> https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/src/main/java/org/jboss/as/arquillian/protocol/jmx/ServerKillerExtension.java
>> Great thing it works for you :)
>> This was written by Stuart & me over some discussion in Brno F2F as 
>> an optional feature that we would use in testsuite for our CI
>> as we had problems with hanging processes.
>> But it ended up not really useful...
>>
>> --
>> tomaz
>>
>>


/max
http://about.me/maxandersen


From tomaz.cerar at gmail.com  Thu Oct  1 08:54:12 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 1 Oct 2015 14:54:12 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <A610F01C-CFFE-4D9B-81F9-33BF2F49C899@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
	<263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
	<560BC9BF.5000200@redhat.com>
	<CAMquZP50rhZ9a76_ov=Eh=fEvsuKdv4Uc+K3RD1wnPnYLwqecA@mail.gmail.com>
	<560BDF00.90106@redhat.com>
	<A610F01C-CFFE-4D9B-81F9-33BF2F49C899@redhat.com>
Message-ID: <CAMquZP5Y6DVTW6x7mNSosncYsEGjfuot=M+UN4SJkRPCJ4q08w@mail.gmail.com>

On Thu, Oct 1, 2015 at 2:31 PM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> okey, so that explain why you like the scripts - these issues manifests
> itself most on windows ;)
>
> so how do you handle running two servers ? it kills all of them ?
>
> got a link to the exact code you use ?
>

If it based on that ServerKiller extension than
look at
https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/src/main/java/org/jboss/as/arquillian/protocol/jmx/ServerKillerExtension.java#L106
and see killLinux(Runtime) and killWindows(Runtime) methods

This code was written to kill all leftover jboss/wildfly processes after
arquillian test run and as such kills all such processes.

Said all that, it is quite simple to modify it to suite what ever need you
have.

powershell command for getting all processes to kill is

gwmi win32_process -filter "name='java.exe' and commandLine like
'%jboss-modules%' "

but that could be further filtered for the needs you might have
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151001/63ab54ed/attachment.html 

From brian.stansberry at redhat.com  Thu Oct  1 09:58:04 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 1 Oct 2015 08:58:04 -0500
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <1058932853.21318065.1443701825792.JavaMail.zimbra@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
	<CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
	<CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>
	<CAMquZP6YmYsbWm4CvM0sLXBaLgkUdvC8XxUR7u18bWPAT6_1JA@mail.gmail.com>
	<1058932853.21318065.1443701825792.JavaMail.zimbra@redhat.com>
Message-ID: <560D3BEC.20309@redhat.com>

On 10/1/15 7:17 AM, Rostislav Svoboda wrote:
>> Right this is my concern. The behavior is different as the bash
>> scripts don't exit. They wait for the process to end. Maybe it's
>> correct to be different, I don't know.
>
> If you send signal 10 (kill -l 10 returns USR1) AS got restarted thanks while loop - https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/bin/standalone.sh#L299
> and it doesn't matter if you execute it normally or with LAUNCH_JBOSS_IN_BACKGROUND
>
> don't know what the real use case is to get it restarted

I'm not certain if you were asking ^^^ in general or just in the context 
of these init scripts. The answer in general is this is what allows the 
:shutdown(restart=true) management operation to work; the restart=true 
causes the process to exit with exit code 10. This relies on the launch 
script understanding this exit code and starting a new process.

> wildfly-init-redhat.sh and wildfly-init-debian.sh do restart by stop&&start
>    	restart)
> 		$0 stop
> 		$0 start
> EAP 6.4.3 RPM init.d script does stop&&start too
>    restart|reload)
>        stop
>        sleep 3
>        start
>        RETVAL=$?
>        ;;
>
> There is some magic in the .sh scripts with number 128 and it's related wait command / bash / signals
>    http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html#sect_12_02_02
>    http://veithen.github.io/2014/11/16/sigterm-propagation.html
>
>>
>> Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much
>> implemented
>> to satisfy the init.d script we have and is not really useful if you run it
>> directly.
>
> it is used in:
>    https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-redhat.sh
>    https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-debian.sh
>
> read kpid < $JBOSS_PIDFILE in stop function
>
>> If that is really so, I am not a fan of having that in standalone.sh
>> directly...
>>
>
> domain.sh has the same mechanism LAUNCH_JBOSS_IN_BACKGROUND + JBOSS_PIDFILE
> If it's removed from both files something will have to be added to the init/systemd scripts.
>
> Cheers.
> Rostislav
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From rsvoboda at redhat.com  Thu Oct  1 10:32:56 2015
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Thu, 1 Oct 2015 10:32:56 -0400 (EDT)
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560D3BEC.20309@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
	<CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
	<CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>
	<CAMquZP6YmYsbWm4CvM0sLXBaLgkUdvC8XxUR7u18bWPAT6_1JA@mail.gmail.com>
	<1058932853.21318065.1443701825792.JavaMail.zimbra@redhat.com>
	<560D3BEC.20309@redhat.com>
Message-ID: <249584940.21527777.1443709976509.JavaMail.zimbra@redhat.com>

> On 10/1/15 7:17 AM, Rostislav Svoboda wrote:
> >> Right this is my concern. The behavior is different as the bash
> >> scripts don't exit. They wait for the process to end. Maybe it's
> >> correct to be different, I don't know.
> >
> > If you send signal 10 (kill -l 10 returns USR1) AS got restarted thanks
> > while loop -
> > https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/bin/standalone.sh#L299
> > and it doesn't matter if you execute it normally or with
> > LAUNCH_JBOSS_IN_BACKGROUND
> >
> > don't know what the real use case is to get it restarted
> 
> I'm not certain if you were asking ^^^ in general or just in the context
> of these init scripts. The answer in general is this is what allows the

This was in general, thanks for explanation.

R.

> :shutdown(restart=true) management operation to work; the restart=true
> causes the process to exit with exit code 10. This relies on the launch
> script understanding this exit code and starting a new process.
> 
> > wildfly-init-redhat.sh and wildfly-init-debian.sh do restart by stop&&start
> >    	restart)
> > 		$0 stop
> > 		$0 start
> > EAP 6.4.3 RPM init.d script does stop&&start too
> >    restart|reload)
> >        stop
> >        sleep 3
> >        start
> >        RETVAL=$?
> >        ;;
> >
> > There is some magic in the .sh scripts with number 128 and it's related
> > wait command / bash / signals
> >    http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_12_02.html#sect_12_02_02
> >    http://veithen.github.io/2014/11/16/sigterm-propagation.html
> >
> >>
> >> Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much
> >> implemented
> >> to satisfy the init.d script we have and is not really useful if you run
> >> it
> >> directly.
> >
> > it is used in:
> >    https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-redhat.sh
> >    https://github.com/wildfly/wildfly-core/blob/master/core-feature-pack/src/main/resources/content/docs/contrib/scripts/init.d/wildfly-init-debian.sh
> >
> > read kpid < $JBOSS_PIDFILE in stop function
> >
> >> If that is really so, I am not a fan of having that in standalone.sh
> >> directly...
> >>
> >
> > domain.sh has the same mechanism LAUNCH_JBOSS_IN_BACKGROUND + JBOSS_PIDFILE
> > If it's removed from both files something will have to be added to the
> > init/systemd scripts.
> >
> > Cheers.
> > Rostislav
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 
> 
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From mkopecky at redhat.com  Fri Oct  2 04:55:37 2015
From: mkopecky at redhat.com (Marek Kopecky)
Date: Fri, 2 Oct 2015 10:55:37 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
Message-ID: <560E4689.9090104@redhat.com>

Hi.

Feedback from GSS could be useful for this topic too. If batch script 
would just do call out to their .ps1 counter parts [1], it may broke 
automatizationof some of our customers.

Marek

[1] https://github.com/wildfly/wildfly-core/pull/1126

On 09/29/2015 05:29 PM, Toma? Cerar wrote:
> Hey guys,
>
>
> just heads up, I've managed to prepare[1] all powershell scripts to 
> replace the aging .bat ones.
>
> New scripts unify most of the shared "code" that all scripts use by 
> including common.ps1,
> and each script only has the code that differs from common behavior 
> they all share.
>
> As result of move we now have much more reliable and faster scripts 
> that share common code,
> which helps with maintaining a lot.
>
> New scripts (domain.ps1 & standalone.ps1) now support --background 
> (also controllable via .conf.ps1)
> option that runs the process in background and remembers its pid and 
> as such add support for
> feature that until now was only in *nix version of scripts.
>
> I would like to propose this PR for inclusion to WildFly 10. As it 
> doesn't alter any existing behavior
> but just adds & improve the script experience on Windows.
>
> As we get to test and verify that new scripts don't break/include any 
> currently available option/action
> I would also like to remove the batch scripts[2], so they would just 
> do call out to their .ps1 counter parts.
>
> Once this scripts get merged, I will send PR to also add PS scripts 
> for WildFly full defined scripts,
> given that most of the functionally is already in "common.ps1" new 
> scripts will be just simple 5 liners [3]
>
>
> --
> tomaz
>
>
> [1] https://github.com/wildfly/wildfly-core/pull/1118
> [2] https://github.com/wildfly/wildfly-core/pull/1126
> [3] 
> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151002/0e9f05b5/attachment-0001.html 

From kustos at gmx.net  Sun Oct  4 10:20:25 2015
From: kustos at gmx.net (Philippe Marschall)
Date: Sun, 04 Oct 2015 16:20:25 +0200
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available on
 jdk9.java.net/jigsaw
In-Reply-To: <55F06C22.1090505@oracle.com>
References: <55F06C22.1090505@oracle.com>
Message-ID: <561135A9.3050601@gmx.net>



On 09.09.2015 19:28, Rory O'Donnell wrote:
>
> Hi Jason/Tomaz,
>
> Early-access builds of JDK 9 with Project Jigsaw are available for
> download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.
>
> The EA builds contain the latest prototype implementation of JSR 376
> <http://openjdk.java.net/projects/jigsaw/spec>, the Java Platform Module
> System,
> as well as that of the JDK-specific APIs and tools described in JEP 261
> <http://openjdk.java.net/jeps/261>.
>
> If you'd like to try out the EA builds, by far the most helpful things
> you can do are:
>
>   *
>
>     Try to run existing applications, without change, on these builds to
>     see whether the module system, or the modularization of the
>     platform, breaks your code or identifies code that depends upon
>     JDK-internal APIs or other unspecified aspects of the platform.

It doesn't start because +XX:MaxPermSize is unknown. Since WildFly 10 is 
Java 8+ should I file a JIRA/PR?

Cheers
Philippe

From brian.stansberry at redhat.com  Sun Oct  4 14:46:10 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Sun, 4 Oct 2015 13:46:10 -0500
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available on
 jdk9.java.net/jigsaw
In-Reply-To: <561135A9.3050601@gmx.net>
References: <55F06C22.1090505@oracle.com> <561135A9.3050601@gmx.net>
Message-ID: <561173F2.40501@redhat.com>

On 10/4/15 9:20 AM, Philippe Marschall wrote:
>
>
> It doesn't start because +XX:MaxPermSize is unknown. Since WildFly 10 is
> Java 8+ should I file a JIRA/PR?
>

What doesn't start?  AFAIK all uses of +XX:MaxPermSize should be gone 
from the WildFly 10 scripts.


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From tomaz.cerar at gmail.com  Sun Oct  4 15:30:46 2015
From: tomaz.cerar at gmail.com (tomaz.cerar at gmail.com)
Date: Sun, 4 Oct 2015 21:30:46 +0200
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available
 onjdk9.java.net/jigsaw
In-Reply-To: <561173F2.40501@redhat.com>
References: <55F06C22.1090505@oracle.com> <561135A9.3050601@gmx.net>
	<561173F2.40501@redhat.com>
Message-ID: <56117e67.e117b40a.7f165.36ad@mx.google.com>

It is gone from all our scripts.

Also most of testsuite passes on jkd9 non jigsaw builds, we havent tested jigsaw builds yet.

Sent from my Phone

-----Original Message-----
From: "Brian Stansberry" <brian.stansberry at redhat.com>
Sent: ?4.?10.?2015 20:46
To: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
Subject: Re: [wildfly-dev] Project Jigsaw: Early-Access Builds available onjdk9.java.net/jigsaw

On 10/4/15 9:20 AM, Philippe Marschall wrote:
>
>
> It doesn't start because +XX:MaxPermSize is unknown. Since WildFly 10 is
> Java 8+ should I file a JIRA/PR?
>

What doesn't start?  AFAIK all uses of +XX:MaxPermSize should be gone 
from the WildFly 10 scripts.


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151004/f60ff368/attachment.html 

From arjan.tijms at gmail.com  Mon Oct  5 09:46:21 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 5 Oct 2015 15:46:21 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
Message-ID: <CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>

Hi,

Just wondering, any updates here? Did you tried to run the JASPIC
tests against the latest nightly?

Kind regards,
Arjan Tijms

On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> Hi,
>
> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com> wrote:
>> Can you verify that this PR: https://github.com/wildfly/wildfly/pull/8204
>> fixes your issues?
>
> I did a quick test run, but now really everything breaks.
>
> In UndertowDeploymentInfoService the following line occurs:
>
>  deploymentInfo.setJaspiAuthenticationMechanism(new
> JASPIAuthenticationMechanism(authMethod, securityDomain));
>
> But the constructor arguments are reversed.
>
> The arguments are defined as:
>
>  public JASPIAuthenticationMechanism(final String securityDomain,
> final String configuredAuthMethod) {
>
> When I reverse the arguments to their correct order, the same tests as
> before fail unfortunately.
>
> This individual case can be rather easily debugged manually by cloning
> the project using Eclipse/JBoss tools from
> https://github.com/javaee-samples/javaee7-samples Then importing just
> the jaspic and test-utils directories as Maven projects, and then
> deploying "jaspic-basic-authentication" using Add and Remove on the
> server.
>
> If you then request:
>
> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>
> You should see the same output as:
>
> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>
> Hope this helps
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>>
>> Basically it reverts the recent changes, and instead installs a handler
>> after authenticate to handle requests that do not require authentication.
>>
>> Stuart
>>
>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com>
>> wrote:
>>>
>>> The MIT license also grants the ability to relicense.
>>>
>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
>>> wrote:
>>>
>>> This was deliberately disabled to match the behavior of EAP6. It can be
>>> controlled by the proactive-authentication attribute on the servlet
>>> container. These JAPIC changes have been driven by this change, in order to
>>> get the TCK to pass without proactive auth. I will look into it today.
>>>
>>> If you can contribute your tests it would be greatly appreciated, we do
>>> not have much coverage (and apparently neither does the TCK, as it does not
>>> pick up these issues). As I understand it if you are the sole author you
>>> retain copyright and can re-license them under whatever license you like.
>>>
>>> Stuart
>>>
>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I discovered some more issues originating from 5298:
>>>>
>>>> pre-emptive authentication on a public page doesn't work anymore
>>>> either. It still worked fine in WildFly 9.0.1.
>>>>
>>>> This can be easily seen when running the JASPIC tests from
>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>
>>>> For the basic authentication tests, the following now fail:
>>>>
>>>> Failed tests:
>>>>
>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>
>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>
>>>> These tests don't rely on request#authenticate, but depend on
>>>> automatic calling of a SAM at the beginning of a request. After manual
>>>> inspection it's clear that the SAM is called, but its outcome is not
>>>> being applied.
>>>>
>>>> Kind regards,
>>>> Arjan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>> > unfortunately the code is still severely broken now.
>>>> >
>>>> > There are two main issues, and they're both in this fragment in
>>>> > JASPIAuthenticationMechanism:
>>>> >
>>>> > if(isValid == null) {
>>>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>>>> > }
>>>> >
>>>> > The first problem is the "isValid == null" check. After the first call
>>>> > to request#authenticate in a given request this will always be
>>>> > non-null. The result is that a request for programmatic authentication
>>>> > will effectively be ignored the first time.
>>>> >
>>>> > The second problem is that this passes in the JBossCallbackHandler,
>>>> > but this doesn't know how to handle JASPIC callbacks and this will
>>>> > result in an exception like the following:
>>>> >
>>>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>>>> > a callback of type
>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>> >     at
>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>> >     at
>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>> >
>>>> > The code should pass in a JASPICallbackHandler here.
>>>> >
>>>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>>>> > "isValid == null" check and passing in the right callback handler.
>>>> >
>>>> > Kind regards,
>>>> > Arjan Tijms
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> > wrote:
>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>>>> >> version, but leaving in the new JASPICInitialHandler, then everything
>>>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>>>> >> some quick testing it does do the trick.
>>>> >>
>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> >> wrote:
>>>> >>> Hi,
>>>> >>>
>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>>> >>>
>>>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>>> >>>
>>>> >>> HttpServletRequest#authenticate calls though to
>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>> >>>
>>>> >>> There it now obtains the attachment that was set by the new
>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>>>> >>> request. And then uses the stored "isValid" outcome directly, without
>>>> >>> calling the SAM again.
>>>> >>>
>>>> >>> See the code below:
>>>> >>>
>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>> >>>         JASPICAttachment attachment =
>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>> >>>
>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>> >>>         Account authenticatedAccount = null;
>>>> >>>
>>>> >>>         boolean isValid = attachment.isValid();
>>>> >>>         final ServletRequestContext requestContext =
>>>> >>> attachment.getRequestContext();
>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>> >>> attachment.getSam();
>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>>> >>>
>>>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>>>> >>>         if (isValid) {
>>>> >>>             // The CBH filled in the JBOSS SecurityContext, we need
>>>> >>> to
>>>> >>> create an Undertow account based on that
>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>> >>> SecurityActions.getSecurityContext();
>>>> >>>             authenticatedAccount =
>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>> >>>         }
>>>> >>>
>>>> >>> This is not correct I think. The code should call the SAM once again
>>>> >>> and use the outcome from that call.
>>>> >>>
>>>> >>> Am I missing something, or was the new call to the SAM simply
>>>> >>> forgotten at this point?
>>>> >>>
>>>> >>> Kind regards,
>>>> >>> Arjan Tijms
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From kustos at gmx.net  Mon Oct  5 13:40:05 2015
From: kustos at gmx.net (Philippe Marschall)
Date: Mon, 05 Oct 2015 19:40:05 +0200
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available on
 jdk9.java.net/jigsaw
In-Reply-To: <561173F2.40501@redhat.com>
References: <55F06C22.1090505@oracle.com> <561135A9.3050601@gmx.net>
	<561173F2.40501@redhat.com>
Message-ID: <5612B5F5.8020802@gmx.net>



On 04.10.2015 20:46, Brian Stansberry wrote:
> On 10/4/15 9:20 AM, Philippe Marschall wrote:
>>
>>
>> It doesn't start because +XX:MaxPermSize is unknown. Since WildFly 10 is
>> Java 8+ should I file a JIRA/PR?
>>
>
> What doesn't start?  AFAIK all uses of +XX:MaxPermSize should be gone
> from the WildFly 10 scripts.

I checked with 9.0.1, my bad.

Cheers
Philippe

From brian.stansberry at redhat.com  Mon Oct  5 14:20:29 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 5 Oct 2015 13:20:29 -0500
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available on
 jdk9.java.net/jigsaw
In-Reply-To: <5612B5F5.8020802@gmx.net>
References: <55F06C22.1090505@oracle.com> <561135A9.3050601@gmx.net>
	<561173F2.40501@redhat.com> <5612B5F5.8020802@gmx.net>
Message-ID: <5612BF6D.3040006@redhat.com>

On 10/5/15 12:40 PM, Philippe Marschall wrote:
>
>
> On 04.10.2015 20:46, Brian Stansberry wrote:
>> On 10/4/15 9:20 AM, Philippe Marschall wrote:
>>>
>>>
>>> It doesn't start because +XX:MaxPermSize is unknown. Since WildFly 10 is
>>> Java 8+ should I file a JIRA/PR?
>>>
>>
>> What doesn't start?  AFAIK all uses of +XX:MaxPermSize should be gone
>> from the WildFly 10 scripts.
>
> I checked with 9.0.1, my bad.
>

Ah, good. :) No problem, Philippe.


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From tomaz.cerar at gmail.com  Thu Oct  8 09:29:25 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 8 Oct 2015 15:29:25 +0200
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
Message-ID: <CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>

On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger at codezen.co.uk>
wrote:

> I just want to re-iterate this to try and get it ready for the final
> Wildfly 10 release. In order to make Redis integration, what changes should
> I be making? In particular;
>
You are too late to get any new feature to 10, CRx build are just bugfixes
of existing stuff and no new features are being added anymore.


>
>
>    1. xml reader/writer - should I be adding redis-store as a concrete
>    xml tag?
>    2. persistence pom updates to add the redis jar dependency
>    3. xsd documentation updates
>    4. module configurations
>    5. jboss-cli - do I need to add a redis-store type to a cache
>    container?
>    6. web management console - again redis-store type to a cache
>    container?
>
>
1,3,5&6 are basically the same thing, you need to add support for
redis-store to infinispan subsystem.
When that is done correctly, cli is done as well.
And once CLI part is done, you can access same stuff via mgmt REST api
which console uses.
In most cases console doesn't need changes for extra fields / resources,
but if it does,
you can send change to HAL project once all of the previous points are done
and change is merged in WildFly master

for general docs about extending WildFly itself look at
https://docs.jboss.org/author/display/WFLY10/Extending+WildFly




>
> 1 - 3 are done, 4 is in progress, however I am unclear on how to make 5
> and 6 (can't find the code locations), and I also want steer on whether a
> concrete store type is needed or if the custom store should be the way to
> go, in which case I think only pom updates and module config is required.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151008/b3b9f6b3/attachment-0001.html 

From ttarrant at redhat.com  Thu Oct  8 11:06:20 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 8 Oct 2015 17:06:20 +0200
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
	<CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
Message-ID: <5616866C.9030801@redhat.com>

Actually, let me expand on Simon's request, since this is something I've 
wanted to have from WF: sub-extensions to extensions (or sub-subsystems).
For this particular use-case, a way for an extension (an Infinispan 
Cache Store) to declare that it is a child of another extension 
(Infinispan). The child extension would be responsible for 
parsing/serializing its own section of the XML, service registration, etc.
Is this planned ?

Thanks

Tristan

On 08/10/2015 15:29, Toma? Cerar wrote:
>
> On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger at codezen.co.uk
> <mailto:spaulger at codezen.co.uk>> wrote:
>
>     I just want to re-iterate this to try and get it ready for the final
>     Wildfly 10 release. In order to make Redis integration, what changes
>     should I be making? In particular;
>
> You are too late to get any new feature to 10, CRx build are just
> bugfixes of existing stuff and no new features are being added anymore.
>
>
>      1. xml reader/writer - should I be adding redis-store as a concrete
>         xml tag?
>      2. persistence pom updates to add the redis jar dependency
>      3. xsd documentation updates
>      4. module configurations
>      5. jboss-cli - do I need to add a redis-store type to a cache
>         container?
>      6. web management console - again redis-store type to a cache
>         container?
>
>
> 1,3,5&6 are basically the same thing, you need to add support for
> redis-store to infinispan subsystem.
> When that is done correctly, cli is done as well.
> And once CLI part is done, you can access same stuff via mgmt REST api
> which console uses.
> In most cases console doesn't need changes for extra fields / resources,
> but if it does,
> you can send change to HAL project once all of the previous points are
> done and change is merged in WildFly master
>
> for general docs about extending WildFly itself look at
> https://docs.jboss.org/author/display/WFLY10/Extending+WildFly
>
>
>
>     1 - 3 are done, 4 is in progress, however I am unclear on how to
>     make 5 and 6 (can't find the code locations), and I also want steer
>     on whether a concrete store type is needed or if the custom store
>     should be the way to go, in which case I think only pom updates and
>     module config is required.
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From tomaz.cerar at gmail.com  Thu Oct  8 11:26:18 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 8 Oct 2015 17:26:18 +0200
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <5616866C.9030801@redhat.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
	<CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
	<5616866C.9030801@redhat.com>
Message-ID: <CAMquZP5+dkk7at1tgCVNNqYuSkKTk_-C77qMaZ_Qd7ujfAs7Ug@mail.gmail.com>

On Thu, Oct 8, 2015 at 5:06 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:

> The child extension would be responsible for
> parsing/serializing its own section of the XML, service registration, etc.
> Is this planned ?
>


Why plan something that is already doable :-)
Well in a way at least, code that handles certain sub resource can be be
anywhere, even in external module/dependancy.
All infinispan subsystem would need to do is .registerChild(new
CacheStoreResourceDefinitionDefinedInDifferentModule())
well at least as long as you use new parser constructs, this would be
trivial.
otherwise extra wiring for parser would be needed.

We do have similar setup for including parts of threads subsystem in other
subsystems.

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151008/f689c42b/attachment.html 

From brian.stansberry at redhat.com  Thu Oct  8 11:26:21 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 8 Oct 2015 10:26:21 -0500
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <5616866C.9030801@redhat.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
	<CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
	<5616866C.9030801@redhat.com>
Message-ID: <56168B1D.60507@redhat.com>

No, not really.

Notions like that have come up a time or two, but I wouldn't say they 
are planned.

This seems like primarily a module loading issue. The parent extension 
needs to be made aware of the presence of an external module so it can 
load classes from it and use those to extend its own management API. 
Those classes would implement an SPI provided by the parent extension. 
That SPI would be a mix of kernel stuff and stuff specific to the parent 
extension

1) specific stuff: things like where "child extension" resources can be 
inserted into the parent tree

2) kernel stuff: various support classes / SPIs that all such cases can 
use to make these things as consistent as possible.

On 10/8/15 10:06 AM, Tristan Tarrant wrote:
> Actually, let me expand on Simon's request, since this is something I've
> wanted to have from WF: sub-extensions to extensions (or sub-subsystems).
> For this particular use-case, a way for an extension (an Infinispan
> Cache Store) to declare that it is a child of another extension
> (Infinispan). The child extension would be responsible for
> parsing/serializing its own section of the XML, service registration, etc.
> Is this planned ?
>
> Thanks
>
> Tristan
>
> On 08/10/2015 15:29, Toma? Cerar wrote:
>>
>> On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger at codezen.co.uk
>> <mailto:spaulger at codezen.co.uk>> wrote:
>>
>>      I just want to re-iterate this to try and get it ready for the final
>>      Wildfly 10 release. In order to make Redis integration, what changes
>>      should I be making? In particular;
>>
>> You are too late to get any new feature to 10, CRx build are just
>> bugfixes of existing stuff and no new features are being added anymore.
>>
>>
>>       1. xml reader/writer - should I be adding redis-store as a concrete
>>          xml tag?
>>       2. persistence pom updates to add the redis jar dependency
>>       3. xsd documentation updates
>>       4. module configurations
>>       5. jboss-cli - do I need to add a redis-store type to a cache
>>          container?
>>       6. web management console - again redis-store type to a cache
>>          container?
>>
>>
>> 1,3,5&6 are basically the same thing, you need to add support for
>> redis-store to infinispan subsystem.
>> When that is done correctly, cli is done as well.
>> And once CLI part is done, you can access same stuff via mgmt REST api
>> which console uses.
>> In most cases console doesn't need changes for extra fields / resources,
>> but if it does,
>> you can send change to HAL project once all of the previous points are
>> done and change is merged in WildFly master
>>
>> for general docs about extending WildFly itself look at
>> https://docs.jboss.org/author/display/WFLY10/Extending+WildFly
>>
>>
>>
>>      1 - 3 are done, 4 is in progress, however I am unclear on how to
>>      make 5 and 6 (can't find the code locations), and I also want steer
>>      on whether a concrete store type is needed or if the custom store
>>      should be the way to go, in which case I think only pom updates and
>>      module config is required.
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From rory.odonnell at oracle.com  Fri Oct  9 04:33:18 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 9 Oct 2015 09:33:18 +0100
Subject: [wildfly-dev] Early Access build 83 for JDK 9 and JDK 9 with
 Project Jigsaw are available for download.
Message-ID: <56177BCE.8090507@oracle.com>


Hi Jason/Tomaz,

JDK 9 with Project Jigsaw Early Access build b83 is available for 
download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.

Notable changes:

  * The -Xoverride option has been extended and renamed to -Xpatch, and
    the -XaddReads option has been restored [1] (changesets
    04dd0430530e, 095fc622bf01).
  * ClassLoader::getPackage now works as it did previously, walking the
    class-loader hierarchy in order to find Package objects, which
    enables NetBeans to start up [2] (5805781b9370).
  * Class::getResource will now return a URL to a resource in a module,
    when invoked from code within that module (0fbe4c72638a).
  * The big module-summary table has been improved, and will now be
    posted with each build [3] (e922b207c170).


JDK 9 Early Access build b83 is available for download 
<https://jdk9.java.net/download/> , summary of  changes are listed here 
<http://download.java.net/jdk9/changes/jdk9-b78.html?q=download/jdk9/changes/jdk9-b83.html>.

  * Request for G1 GC Feedback at wiki -
    https://wiki.openjdk.java.net/display/HotSpot/G1GC+Feedback
  * This wiki-page aims to outline the basic JVM parameters switching to
    G1GC, and how you can help collecting data comparing the G1GC and
    Parallel GC.

Rgds, Rory

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004740.html
[2]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004730.html
[3]http://cr.openjdk.java.net/~mr/jigsaw/ea/module-summary.html


-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151009/c728c745/attachment.html 

From arjan.tijms at gmail.com  Tue Oct 13 07:16:33 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Tue, 13 Oct 2015 13:16:33 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
Message-ID: <CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>

Hi,

Sorry to ask again, but any news on this topic yet?

If there's anything I can do to help just let me know.

Kind regards,
Arjan Tijms






On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> Hi,
>
> Just wondering, any updates here? Did you tried to run the JASPIC
> tests against the latest nightly?
>
> Kind regards,
> Arjan Tijms
>
> On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> Hi,
>>
>> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>> <stuart.w.douglas at gmail.com> wrote:
>>> Can you verify that this PR: https://github.com/wildfly/wildfly/pull/8204
>>> fixes your issues?
>>
>> I did a quick test run, but now really everything breaks.
>>
>> In UndertowDeploymentInfoService the following line occurs:
>>
>>  deploymentInfo.setJaspiAuthenticationMechanism(new
>> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>
>> But the constructor arguments are reversed.
>>
>> The arguments are defined as:
>>
>>  public JASPIAuthenticationMechanism(final String securityDomain,
>> final String configuredAuthMethod) {
>>
>> When I reverse the arguments to their correct order, the same tests as
>> before fail unfortunately.
>>
>> This individual case can be rather easily debugged manually by cloning
>> the project using Eclipse/JBoss tools from
>> https://github.com/javaee-samples/javaee7-samples Then importing just
>> the jaspic and test-utils directories as Maven projects, and then
>> deploying "jaspic-basic-authentication" using Add and Remove on the
>> server.
>>
>> If you then request:
>>
>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>
>> You should see the same output as:
>>
>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>
>> Hope this helps
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>>
>>> Basically it reverts the recent changes, and instead installs a handler
>>> after authenticate to handle requests that do not require authentication.
>>>
>>> Stuart
>>>
>>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com>
>>> wrote:
>>>>
>>>> The MIT license also grants the ability to relicense.
>>>>
>>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
>>>> wrote:
>>>>
>>>> This was deliberately disabled to match the behavior of EAP6. It can be
>>>> controlled by the proactive-authentication attribute on the servlet
>>>> container. These JAPIC changes have been driven by this change, in order to
>>>> get the TCK to pass without proactive auth. I will look into it today.
>>>>
>>>> If you can contribute your tests it would be greatly appreciated, we do
>>>> not have much coverage (and apparently neither does the TCK, as it does not
>>>> pick up these issues). As I understand it if you are the sole author you
>>>> retain copyright and can re-license them under whatever license you like.
>>>>
>>>> Stuart
>>>>
>>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I discovered some more issues originating from 5298:
>>>>>
>>>>> pre-emptive authentication on a public page doesn't work anymore
>>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>
>>>>> This can be easily seen when running the JASPIC tests from
>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>
>>>>> For the basic authentication tests, the following now fail:
>>>>>
>>>>> Failed tests:
>>>>>
>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>
>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>
>>>>> These tests don't rely on request#authenticate, but depend on
>>>>> automatic calling of a SAM at the beginning of a request. After manual
>>>>> inspection it's clear that the SAM is called, but its outcome is not
>>>>> being applied.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>> > unfortunately the code is still severely broken now.
>>>>> >
>>>>> > There are two main issues, and they're both in this fragment in
>>>>> > JASPIAuthenticationMechanism:
>>>>> >
>>>>> > if(isValid == null) {
>>>>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>>>>> > }
>>>>> >
>>>>> > The first problem is the "isValid == null" check. After the first call
>>>>> > to request#authenticate in a given request this will always be
>>>>> > non-null. The result is that a request for programmatic authentication
>>>>> > will effectively be ignored the first time.
>>>>> >
>>>>> > The second problem is that this passes in the JBossCallbackHandler,
>>>>> > but this doesn't know how to handle JASPIC callbacks and this will
>>>>> > result in an exception like the following:
>>>>> >
>>>>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>>>>> > a callback of type
>>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>>> >     at
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>> >     at
>>>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>> >
>>>>> > The code should pass in a JASPICallbackHandler here.
>>>>> >
>>>>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>>>>> > "isValid == null" check and passing in the right callback handler.
>>>>> >
>>>>> > Kind regards,
>>>>> > Arjan Tijms
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> > wrote:
>>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>>>>> >> version, but leaving in the new JASPICInitialHandler, then everything
>>>>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>>>>> >> some quick testing it does do the trick.
>>>>> >>
>>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> >> wrote:
>>>>> >>> Hi,
>>>>> >>>
>>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>>>> >>>
>>>>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>>>> >>>
>>>>> >>> HttpServletRequest#authenticate calls though to
>>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>> >>>
>>>>> >>> There it now obtains the attachment that was set by the new
>>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>>>>> >>> request. And then uses the stored "isValid" outcome directly, without
>>>>> >>> calling the SAM again.
>>>>> >>>
>>>>> >>> See the code below:
>>>>> >>>
>>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>> >>>         JASPICAttachment attachment =
>>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>> >>>
>>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>> >>>         Account authenticatedAccount = null;
>>>>> >>>
>>>>> >>>         boolean isValid = attachment.isValid();
>>>>> >>>         final ServletRequestContext requestContext =
>>>>> >>> attachment.getRequestContext();
>>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>> >>> attachment.getSam();
>>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>>>> >>>
>>>>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>>>>> >>>         if (isValid) {
>>>>> >>>             // The CBH filled in the JBOSS SecurityContext, we need
>>>>> >>> to
>>>>> >>> create an Undertow account based on that
>>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>> >>> SecurityActions.getSecurityContext();
>>>>> >>>             authenticatedAccount =
>>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>> >>>         }
>>>>> >>>
>>>>> >>> This is not correct I think. The code should call the SAM once again
>>>>> >>> and use the outcome from that call.
>>>>> >>>
>>>>> >>> Am I missing something, or was the new call to the SAM simply
>>>>> >>> forgotten at this point?
>>>>> >>>
>>>>> >>> Kind regards,
>>>>> >>> Arjan Tijms
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From spaulger at codezen.co.uk  Sun Oct 18 16:04:47 2015
From: spaulger at codezen.co.uk (Simon Paulger)
Date: Sun, 18 Oct 2015 21:04:47 +0100
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <56168B1D.60507@redhat.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
	<CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
	<5616866C.9030801@redhat.com> <56168B1D.60507@redhat.com>
Message-ID: <CAHadGsttv2QoVF4d9VZWdACFYdfGEx7Mw_QDNEvsPZRSu5_KmQ@mail.gmail.com>

Hi,

Sorry for the delay in getting back to you all.

In terms of what I've developed, I have uploaded the development branch
here: https://github.com/spaulg/wildfly/tree/feature/redis-support.

This includes all changes I've made, which I've recently merged in
10.0.0CR2. I know this won't be added to that release, but it means I can
track against a stable and current branch.

Regarding Tristan's comment and Tomaz's reply for having subextensions of
extensions, what I have developed simply matches the existing approach used
by the Remote store. I have created a StoreBuilder, BuilderFactory and
ResourceDefinition for the Redis store and registered this in to the XML
reader/writer for the Infinispan subsystem. This means when the
configuration has a redis-store tag as a cache store that has its own
configuration attributes.

In terms of the cli/web and the changes that need to be made. I have made
all the xsd changes and amending the xml reader/writer for the new store,
however its failing unit tests with the error below. I'm not sure why.

testDescribeHandler[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase)
> Time elapsed: 0.023 sec  <<< ERROR!
> java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed:
> java.util.MissingResourceException: Can't find resource for bundle
> java.util.PropertyResourceBundle, key infinispan.local-cache.redis-store"
> at
> org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581)
> at
> org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118)
> at
> org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:669)
> at
> org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testDescribeHandler(SubsystemParsingTestCase.java:187)


Kind regards,

> Simon

On 8 October 2015 at 16:26, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> No, not really.
>
> Notions like that have come up a time or two, but I wouldn't say they
> are planned.
>
> This seems like primarily a module loading issue. The parent extension
> needs to be made aware of the presence of an external module so it can
> load classes from it and use those to extend its own management API.
> Those classes would implement an SPI provided by the parent extension.
> That SPI would be a mix of kernel stuff and stuff specific to the parent
> extension
>
> 1) specific stuff: things like where "child extension" resources can be
> inserted into the parent tree
>
> 2) kernel stuff: various support classes / SPIs that all such cases can
> use to make these things as consistent as possible.
>
> On 10/8/15 10:06 AM, Tristan Tarrant wrote:
> > Actually, let me expand on Simon's request, since this is something I've
> > wanted to have from WF: sub-extensions to extensions (or sub-subsystems).
> > For this particular use-case, a way for an extension (an Infinispan
> > Cache Store) to declare that it is a child of another extension
> > (Infinispan). The child extension would be responsible for
> > parsing/serializing its own section of the XML, service registration,
> etc.
> > Is this planned ?
> >
> > Thanks
> >
> > Tristan
> >
> > On 08/10/2015 15:29, Toma? Cerar wrote:
> >>
> >> On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <spaulger at codezen.co.uk
> >> <mailto:spaulger at codezen.co.uk>> wrote:
> >>
> >>      I just want to re-iterate this to try and get it ready for the
> final
> >>      Wildfly 10 release. In order to make Redis integration, what
> changes
> >>      should I be making? In particular;
> >>
> >> You are too late to get any new feature to 10, CRx build are just
> >> bugfixes of existing stuff and no new features are being added anymore.
> >>
> >>
> >>       1. xml reader/writer - should I be adding redis-store as a
> concrete
> >>          xml tag?
> >>       2. persistence pom updates to add the redis jar dependency
> >>       3. xsd documentation updates
> >>       4. module configurations
> >>       5. jboss-cli - do I need to add a redis-store type to a cache
> >>          container?
> >>       6. web management console - again redis-store type to a cache
> >>          container?
> >>
> >>
> >> 1,3,5&6 are basically the same thing, you need to add support for
> >> redis-store to infinispan subsystem.
> >> When that is done correctly, cli is done as well.
> >> And once CLI part is done, you can access same stuff via mgmt REST api
> >> which console uses.
> >> In most cases console doesn't need changes for extra fields / resources,
> >> but if it does,
> >> you can send change to HAL project once all of the previous points are
> >> done and change is merged in WildFly master
> >>
> >> for general docs about extending WildFly itself look at
> >> https://docs.jboss.org/author/display/WFLY10/Extending+WildFly
> >>
> >>
> >>
> >>      1 - 3 are done, 4 is in progress, however I am unclear on how to
> >>      make 5 and 6 (can't find the code locations), and I also want steer
> >>      on whether a concrete store type is needed or if the custom store
> >>      should be the way to go, in which case I think only pom updates and
> >>      module config is required.
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151018/0bdd6075/attachment.html 

From tomaz.cerar at gmail.com  Mon Oct 19 05:23:49 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Mon, 19 Oct 2015 11:23:49 +0200
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <CAHadGsttv2QoVF4d9VZWdACFYdfGEx7Mw_QDNEvsPZRSu5_KmQ@mail.gmail.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
	<CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>
	<CAMquZP7s8OVWQrej02kcZ2XxqqVzPxPxS37NYEQtekTJzsNrRQ@mail.gmail.com>
	<5616866C.9030801@redhat.com> <56168B1D.60507@redhat.com>
	<CAHadGsttv2QoVF4d9VZWdACFYdfGEx7Mw_QDNEvsPZRSu5_KmQ@mail.gmail.com>
Message-ID: <CAMquZP7_Ooo0yYqOdjHv9ARusLt6NC73djoDaGCRxhFU=nGK3w@mail.gmail.com>

You are missing text description of the key you added.
They are usually stored in LocalDescriptions.properties of your module.
for infinispan subsystem that would probably be in
src/main/resources/org/jboss/as/clustering/infinispan/subsystem/LocalDescriptions.properties

On Sun, Oct 18, 2015 at 10:04 PM, Simon Paulger <spaulger at codezen.co.uk>
wrote:

> Hi,
>
> Sorry for the delay in getting back to you all.
>
> In terms of what I've developed, I have uploaded the development branch
> here: https://github.com/spaulg/wildfly/tree/feature/redis-support.
>
> This includes all changes I've made, which I've recently merged in
> 10.0.0CR2. I know this won't be added to that release, but it means I can
> track against a stable and current branch.
>
> Regarding Tristan's comment and Tomaz's reply for having subextensions of
> extensions, what I have developed simply matches the existing approach used
> by the Remote store. I have created a StoreBuilder, BuilderFactory and
> ResourceDefinition for the Redis store and registered this in to the XML
> reader/writer for the Infinispan subsystem. This means when the
> configuration has a redis-store tag as a cache store that has its own
> configuration attributes.
>
> In terms of the cli/web and the changes that need to be made. I have made
> all the xsd changes and amending the xml reader/writer for the new store,
> however its failing unit tests with the error below. I'm not sure why.
>
> testDescribeHandler[8](org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase)
>> Time elapsed: 0.023 sec  <<< ERROR!
>> java.lang.RuntimeException: "WFLYCTL0158: Operation handler failed:
>> java.util.MissingResourceException: Can't find resource for bundle
>> java.util.PropertyResourceBundle, key infinispan.local-cache.redis-store"
>> at
>> org.jboss.as.subsystem.test.SubsystemTestDelegate.validateDescriptionProviders(SubsystemTestDelegate.java:581)
>> at
>> org.jboss.as.subsystem.test.SubsystemTestDelegate.access$500(SubsystemTestDelegate.java:118)
>> at
>> org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:669)
>> at
>> org.jboss.as.clustering.infinispan.subsystem.SubsystemParsingTestCase.testDescribeHandler(SubsystemParsingTestCase.java:187)
>
>
> Kind regards,
>
>> Simon
>
> On 8 October 2015 at 16:26, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
>> No, not really.
>>
>> Notions like that have come up a time or two, but I wouldn't say they
>> are planned.
>>
>> This seems like primarily a module loading issue. The parent extension
>> needs to be made aware of the presence of an external module so it can
>> load classes from it and use those to extend its own management API.
>> Those classes would implement an SPI provided by the parent extension.
>> That SPI would be a mix of kernel stuff and stuff specific to the parent
>> extension
>>
>> 1) specific stuff: things like where "child extension" resources can be
>> inserted into the parent tree
>>
>> 2) kernel stuff: various support classes / SPIs that all such cases can
>> use to make these things as consistent as possible.
>>
>> On 10/8/15 10:06 AM, Tristan Tarrant wrote:
>> > Actually, let me expand on Simon's request, since this is something I've
>> > wanted to have from WF: sub-extensions to extensions (or
>> sub-subsystems).
>> > For this particular use-case, a way for an extension (an Infinispan
>> > Cache Store) to declare that it is a child of another extension
>> > (Infinispan). The child extension would be responsible for
>> > parsing/serializing its own section of the XML, service registration,
>> etc.
>> > Is this planned ?
>> >
>> > Thanks
>> >
>> > Tristan
>> >
>> > On 08/10/2015 15:29, Toma? Cerar wrote:
>> >>
>> >> On Sat, Sep 26, 2015 at 11:12 PM, Simon Paulger <
>> spaulger at codezen.co.uk
>> >> <mailto:spaulger at codezen.co.uk>> wrote:
>> >>
>> >>      I just want to re-iterate this to try and get it ready for the
>> final
>> >>      Wildfly 10 release. In order to make Redis integration, what
>> changes
>> >>      should I be making? In particular;
>> >>
>> >> You are too late to get any new feature to 10, CRx build are just
>> >> bugfixes of existing stuff and no new features are being added anymore.
>> >>
>> >>
>> >>       1. xml reader/writer - should I be adding redis-store as a
>> concrete
>> >>          xml tag?
>> >>       2. persistence pom updates to add the redis jar dependency
>> >>       3. xsd documentation updates
>> >>       4. module configurations
>> >>       5. jboss-cli - do I need to add a redis-store type to a cache
>> >>          container?
>> >>       6. web management console - again redis-store type to a cache
>> >>          container?
>> >>
>> >>
>> >> 1,3,5&6 are basically the same thing, you need to add support for
>> >> redis-store to infinispan subsystem.
>> >> When that is done correctly, cli is done as well.
>> >> And once CLI part is done, you can access same stuff via mgmt REST api
>> >> which console uses.
>> >> In most cases console doesn't need changes for extra fields /
>> resources,
>> >> but if it does,
>> >> you can send change to HAL project once all of the previous points are
>> >> done and change is merged in WildFly master
>> >>
>> >> for general docs about extending WildFly itself look at
>> >> https://docs.jboss.org/author/display/WFLY10/Extending+WildFly
>> >>
>> >>
>> >>
>> >>      1 - 3 are done, 4 is in progress, however I am unclear on how to
>> >>      make 5 and 6 (can't find the code locations), and I also want
>> steer
>> >>      on whether a concrete store type is needed or if the custom store
>> >>      should be the way to go, in which case I think only pom updates
>> and
>> >>      module config is required.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151019/4f358eba/attachment-0001.html 

From Andreas.Kalk at nordsee.com  Mon Oct 19 10:01:07 2015
From: Andreas.Kalk at nordsee.com (Andreas.Kalk at nordsee.com)
Date: Mon, 19 Oct 2015 16:01:07 +0200
Subject: [wildfly-dev] =?iso-8859-1?q?AUTO=3A_Andreas_Kalk_ist_au=DFer_Hau?=
 =?iso-8859-1?q?s_=28R=FCckkehr_am_28=2E10=2E2015=29__=5BVirus_checked=5D?=
Message-ID: <OFECB2DDAB.E719C7DA-ONC1257EE3.004D01D3-C1257EE3.004D01D3@nordsee.com>


Ich kehre zur?ck am 28.10.2015.

Ich werde ab 19.10.2015 nicht im B?ro sein. Ich kehre zur?ck am
28.10.2015.
Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten.

In dringenden F?llen wenden Sie sich bitte an den Support (1377)


Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht
"wildfly-dev Digest, Vol 31, Issue 4  [Virus checked]" gesendet am
19.10.2015 11:23:54.

Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend
diese Person abwesend ist.

NORDSEE - Wir sind Fisch.
Jetzt neu! Kabeljaufilet vom Grill mit Karotten & Erbsen-Kartoffel-Stampf
"frisch f?r dich" - direkt nach der Bestellung frisch f?r dich zubereitet.
--

P Denken Sie bitte an die Umwelt - bevor Sie ausdrucken!




NORDSEE Holding GmbH * Klu?mannstra?e 3 * 27570 Bremerhaven
Registergericht Bremen * Reg.-Nr. HRB 3579
Gesch?ftsf?hrer: Hiltrud Seggewi? (Vors.) * Robert Jung  * Claus Schl?ter
Aufsichtsratsvorsitzender: Heiner Kamps


From arjan.tijms at gmail.com  Tue Oct 20 18:02:56 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 21 Oct 2015 00:02:56 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
Message-ID: <CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>

Hi,

I just tested WildFly 10.0.0 rc3 and the revert seems to have gone well,
since the behaviour is back to that of WildFly 9.

Meaning, most tests from the EE 7 samples now pass again, but calling of
secureResponse (which 5298 was supposed to fix I think) now fails again:

testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
SAM method secureResponse not called, but should have been.


The JSF includes still fail too, but those were failing in WildFly 9 as
well:

testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
Response did not contain output from JSF view that SAM included.

testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
Response did not contain output from JSF view that SAM included.

Kind regards,
Arjan Tijms







On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> Sorry to ask again, but any news on this topic yet?
>
> If there's anything I can do to help just let me know.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> > Hi,
> >
> > Just wondering, any updates here? Did you tried to run the JASPIC
> > tests against the latest nightly?
> >
> > Kind regards,
> > Arjan Tijms
> >
> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >> Hi,
> >>
> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
> >> <stuart.w.douglas at gmail.com> wrote:
> >>> Can you verify that this PR:
> https://github.com/wildfly/wildfly/pull/8204
> >>> fixes your issues?
> >>
> >> I did a quick test run, but now really everything breaks.
> >>
> >> In UndertowDeploymentInfoService the following line occurs:
> >>
> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
> >>
> >> But the constructor arguments are reversed.
> >>
> >> The arguments are defined as:
> >>
> >>  public JASPIAuthenticationMechanism(final String securityDomain,
> >> final String configuredAuthMethod) {
> >>
> >> When I reverse the arguments to their correct order, the same tests as
> >> before fail unfortunately.
> >>
> >> This individual case can be rather easily debugged manually by cloning
> >> the project using Eclipse/JBoss tools from
> >> https://github.com/javaee-samples/javaee7-samples Then importing just
> >> the jaspic and test-utils directories as Maven projects, and then
> >> deploying "jaspic-basic-authentication" using Add and Remove on the
> >> server.
> >>
> >> If you then request:
> >>
> >>
> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
> >>
> >> You should see the same output as:
> >>
> >>
> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
> >>
> >> Hope this helps
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> Basically it reverts the recent changes, and instead installs a handler
> >>> after authenticate to handle requests that do not require
> authentication.
> >>>
> >>> Stuart
> >>>
> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com>
> >>> wrote:
> >>>>
> >>>> The MIT license also grants the ability to relicense.
> >>>>
> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
> stuart.w.douglas at gmail.com>
> >>>> wrote:
> >>>>
> >>>> This was deliberately disabled to match the behavior of EAP6. It can
> be
> >>>> controlled by the proactive-authentication attribute on the servlet
> >>>> container. These JAPIC changes have been driven by this change, in
> order to
> >>>> get the TCK to pass without proactive auth. I will look into it today.
> >>>>
> >>>> If you can contribute your tests it would be greatly appreciated, we
> do
> >>>> not have much coverage (and apparently neither does the TCK, as it
> does not
> >>>> pick up these issues). As I understand it if you are the sole author
> you
> >>>> retain copyright and can re-license them under whatever license you
> like.
> >>>>
> >>>> Stuart
> >>>>
> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I discovered some more issues originating from 5298:
> >>>>>
> >>>>> pre-emptive authentication on a public page doesn't work anymore
> >>>>> either. It still worked fine in WildFly 9.0.1.
> >>>>>
> >>>>> This can be easily seen when running the JASPIC tests from
> >>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
> >>>>>
> >>>>> For the basic authentication tests, the following now fail:
> >>>>>
> >>>>> Failed tests:
> >>>>>
> >>>>>
> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
> >>>>>
> >>>>>
> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
> >>>>>
> >>>>> These tests don't rely on request#authenticate, but depend on
> >>>>> automatic calling of a SAM at the beginning of a request. After
> manual
> >>>>> inspection it's clear that the SAM is called, but its outcome is not
> >>>>> being applied.
> >>>>>
> >>>>> Kind regards,
> >>>>> Arjan
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
> >>>>> wrote:
> >>>>> > Hi,
> >>>>> >
> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
> >>>>> > unfortunately the code is still severely broken now.
> >>>>> >
> >>>>> > There are two main issues, and they're both in this fragment in
> >>>>> > JASPIAuthenticationMechanism:
> >>>>> >
> >>>>> > if(isValid == null) {
> >>>>> >     isValid =
> createJASPIAuthenticationManager().isValid(messageInfo,
> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
> >>>>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
> >>>>> > }
> >>>>> >
> >>>>> > The first problem is the "isValid == null" check. After the first
> call
> >>>>> > to request#authenticate in a given request this will always be
> >>>>> > non-null. The result is that a request for programmatic
> authentication
> >>>>> > will effectively be ignored the first time.
> >>>>> >
> >>>>> > The second problem is that this passes in the JBossCallbackHandler,
> >>>>> > but this doesn't know how to handle JASPIC callbacks and this will
> >>>>> > result in an exception like the following:
> >>>>> >
> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
> PBOX00014:
> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not
> handle
> >>>>> > a callback of type
> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
> >>>>> >     at
> >>>>> >
> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
> >>>>> >     at
> >>>>> >
> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
> >>>>> >
> >>>>> > The code should pass in a JASPICallbackHandler here.
> >>>>> >
> >>>>> > Hope this can be fixed. Perhaps it's just a matter of removing the
> >>>>> > "isValid == null" check and passing in the right callback handler.
> >>>>> >
> >>>>> > Kind regards,
> >>>>> > Arjan Tijms
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
> arjan.tijms at gmail.com>
> >>>>> > wrote:
> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
> everything
> >>>>> >> seems to work again. This is a bit of hacky workaround perhaps,
> but in
> >>>>> >> some quick testing it does do the trick.
> >>>>> >>
> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
> arjan.tijms at gmail.com>
> >>>>> >> wrote:
> >>>>> >>> Hi,
> >>>>> >>>
> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
> >>>>> >>>
> >>>>> >>>
> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
> )
> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
> >>>>> >>>
> >>>>> >>> HttpServletRequest#authenticate calls though to
> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
> >>>>> >>>
> >>>>> >>> There it now obtains the attachment that was set by the new
> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
> >>>>> >>> request. And then uses the stored "isValid" outcome directly,
> without
> >>>>> >>> calling the SAM again.
> >>>>> >>>
> >>>>> >>> See the code below:
> >>>>> >>>
> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
> >>>>> >>>         JASPICAttachment attachment =
> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
> >>>>> >>>
> >>>>> >>>         AuthenticationMechanismOutcome outcome;
> >>>>> >>>         Account authenticatedAccount = null;
> >>>>> >>>
> >>>>> >>>         boolean isValid = attachment.isValid();
> >>>>> >>>         final ServletRequestContext requestContext =
> >>>>> >>> attachment.getRequestContext();
> >>>>> >>>         final JASPIServerAuthenticationManager sam =
> >>>>> >>> attachment.getSam();
> >>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
> >>>>> >>>
> >>>>> >>>         GenericMessageInfo messageInfo =
> attachment.getMessageInfo();
> >>>>> >>>         if (isValid) {
> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext, we
> need
> >>>>> >>> to
> >>>>> >>> create an Undertow account based on that
> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
> >>>>> >>> SecurityActions.getSecurityContext();
> >>>>> >>>             authenticatedAccount =
> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
> >>>>> >>>         }
> >>>>> >>>
> >>>>> >>> This is not correct I think. The code should call the SAM once
> again
> >>>>> >>> and use the outcome from that call.
> >>>>> >>>
> >>>>> >>> Am I missing something, or was the new call to the SAM simply
> >>>>> >>> forgotten at this point?
> >>>>> >>>
> >>>>> >>> Kind regards,
> >>>>> >>> Arjan Tijms
> >>>>> _______________________________________________
> >>>>> wildfly-dev mailing list
> >>>>> wildfly-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/c36b840f/attachment-0001.html 

From stuart.w.douglas at gmail.com  Tue Oct 20 18:26:45 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 20 Oct 2015 22:26:45 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
Message-ID: <CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>

Is this with proactive auth disabled?

Stuart

On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone well,
> since the behaviour is back to that of WildFly 9.
>
> Meaning, most tests from the EE 7 samples now pass again, but calling of
> secureResponse (which 5298 was supposed to fix I think) now fails again:
>
> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
> SAM method secureResponse not called, but should have been.
>
>
> The JSF includes still fail too, but those were failing in WildFly 9 as
> well:
>
> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
> Response did not contain output from JSF view that SAM included.
>
> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
> Response did not contain output from JSF view that SAM included.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
>
>> Hi,
>>
>> Sorry to ask again, but any news on this topic yet?
>>
>> If there's anything I can do to help just let me know.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > Just wondering, any updates here? Did you tried to run the JASPIC
>> > tests against the latest nightly?
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> >> Hi,
>> >>
>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>> >> <stuart.w.douglas at gmail.com> wrote:
>> >>> Can you verify that this PR:
>> https://github.com/wildfly/wildfly/pull/8204
>> >>> fixes your issues?
>> >>
>> >> I did a quick test run, but now really everything breaks.
>> >>
>> >> In UndertowDeploymentInfoService the following line occurs:
>> >>
>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>> >>
>> >> But the constructor arguments are reversed.
>> >>
>> >> The arguments are defined as:
>> >>
>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>> >> final String configuredAuthMethod) {
>> >>
>> >> When I reverse the arguments to their correct order, the same tests as
>> >> before fail unfortunately.
>> >>
>> >> This individual case can be rather easily debugged manually by cloning
>> >> the project using Eclipse/JBoss tools from
>> >> https://github.com/javaee-samples/javaee7-samples Then importing just
>> >> the jaspic and test-utils directories as Maven projects, and then
>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>> >> server.
>> >>
>> >> If you then request:
>> >>
>> >>
>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>> >>
>> >> You should see the same output as:
>> >>
>> >>
>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>> >>
>> >> Hope this helps
>> >>
>> >> Kind regards,
>> >> Arjan Tijms
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>> Basically it reverts the recent changes, and instead installs a
>> handler
>> >>> after authenticate to handle requests that do not require
>> authentication.
>> >>>
>> >>> Stuart
>> >>>
>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com
>> >
>> >>> wrote:
>> >>>>
>> >>>> The MIT license also grants the ability to relicense.
>> >>>>
>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>> stuart.w.douglas at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> This was deliberately disabled to match the behavior of EAP6. It can
>> be
>> >>>> controlled by the proactive-authentication attribute on the servlet
>> >>>> container. These JAPIC changes have been driven by this change, in
>> order to
>> >>>> get the TCK to pass without proactive auth. I will look into it
>> today.
>> >>>>
>> >>>> If you can contribute your tests it would be greatly appreciated, we
>> do
>> >>>> not have much coverage (and apparently neither does the TCK, as it
>> does not
>> >>>> pick up these issues). As I understand it if you are the sole author
>> you
>> >>>> retain copyright and can re-license them under whatever license you
>> like.
>> >>>>
>> >>>> Stuart
>> >>>>
>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I discovered some more issues originating from 5298:
>> >>>>>
>> >>>>> pre-emptive authentication on a public page doesn't work anymore
>> >>>>> either. It still worked fine in WildFly 9.0.1.
>> >>>>>
>> >>>>> This can be easily seen when running the JASPIC tests from
>> >>>>>
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>> >>>>>
>> >>>>> For the basic authentication tests, the following now fail:
>> >>>>>
>> >>>>> Failed tests:
>> >>>>>
>> >>>>>
>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>> >>>>>
>> >>>>>
>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>> >>>>>
>> >>>>> These tests don't rely on request#authenticate, but depend on
>> >>>>> automatic calling of a SAM at the beginning of a request. After
>> manual
>> >>>>> inspection it's clear that the SAM is called, but its outcome is not
>> >>>>> being applied.
>> >>>>>
>> >>>>> Kind regards,
>> >>>>> Arjan
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com
>> >
>> >>>>> wrote:
>> >>>>> > Hi,
>> >>>>> >
>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>> >>>>> > unfortunately the code is still severely broken now.
>> >>>>> >
>> >>>>> > There are two main issues, and they're both in this fragment in
>> >>>>> > JASPIAuthenticationMechanism:
>> >>>>> >
>> >>>>> > if(isValid == null) {
>> >>>>> >     isValid =
>> createJASPIAuthenticationManager().isValid(messageInfo,
>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> >>>>> > attachment.getApplicationIdentifier(), new
>> JBossCallbackHandler());
>> >>>>> > }
>> >>>>> >
>> >>>>> > The first problem is the "isValid == null" check. After the first
>> call
>> >>>>> > to request#authenticate in a given request this will always be
>> >>>>> > non-null. The result is that a request for programmatic
>> authentication
>> >>>>> > will effectively be ignored the first time.
>> >>>>> >
>> >>>>> > The second problem is that this passes in the
>> JBossCallbackHandler,
>> >>>>> > but this doesn't know how to handle JASPIC callbacks and this will
>> >>>>> > result in an exception like the following:
>> >>>>> >
>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>> PBOX00014:
>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not
>> handle
>> >>>>> > a callback of type
>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >>>>> >     at
>> >>>>> >
>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >>>>> >     at
>> >>>>> >
>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >>>>> >
>> >>>>> > The code should pass in a JASPICallbackHandler here.
>> >>>>> >
>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> >>>>> > "isValid == null" check and passing in the right callback handler.
>> >>>>> >
>> >>>>> > Kind regards,
>> >>>>> > Arjan Tijms
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>> arjan.tijms at gmail.com>
>> >>>>> > wrote:
>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>> previous
>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>> everything
>> >>>>> >> seems to work again. This is a bit of hacky workaround perhaps,
>> but in
>> >>>>> >> some quick testing it does do the trick.
>> >>>>> >>
>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>> arjan.tijms at gmail.com>
>> >>>>> >> wrote:
>> >>>>> >>> Hi,
>> >>>>> >>>
>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>>>> >>>
>> >>>>> >>>
>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>> )
>> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>>> >>>
>> >>>>> >>> HttpServletRequest#authenticate calls though to
>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>>> >>>
>> >>>>> >>> There it now obtains the attachment that was set by the new
>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of
>> the
>> >>>>> >>> request. And then uses the stored "isValid" outcome directly,
>> without
>> >>>>> >>> calling the SAM again.
>> >>>>> >>>
>> >>>>> >>> See the code below:
>> >>>>> >>>
>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>>> >>>         JASPICAttachment attachment =
>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>>> >>>
>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>>> >>>         Account authenticatedAccount = null;
>> >>>>> >>>
>> >>>>> >>>         boolean isValid = attachment.isValid();
>> >>>>> >>>         final ServletRequestContext requestContext =
>> >>>>> >>> attachment.getRequestContext();
>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>> >>>>> >>> attachment.getSam();
>> >>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>>> >>>
>> >>>>> >>>         GenericMessageInfo messageInfo =
>> attachment.getMessageInfo();
>> >>>>> >>>         if (isValid) {
>> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext, we
>> need
>> >>>>> >>> to
>> >>>>> >>> create an Undertow account based on that
>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>>>> >>> SecurityActions.getSecurityContext();
>> >>>>> >>>             authenticatedAccount =
>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>>> >>>         }
>> >>>>> >>>
>> >>>>> >>> This is not correct I think. The code should call the SAM once
>> again
>> >>>>> >>> and use the outcome from that call.
>> >>>>> >>>
>> >>>>> >>> Am I missing something, or was the new call to the SAM simply
>> >>>>> >>> forgotten at this point?
>> >>>>> >>>
>> >>>>> >>> Kind regards,
>> >>>>> >>> Arjan Tijms
>> >>>>> _______________________________________________
>> >>>>> wildfly-dev mailing list
>> >>>>> wildfly-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>>>
>> >>>> _______________________________________________
>> >>>> wildfly-dev mailing list
>> >>>> wildfly-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151020/83926109/attachment-0001.html 

From arjan.tijms at gmail.com  Tue Oct 20 19:04:22 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 21 Oct 2015 01:04:22 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
Message-ID: <CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>

On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> Is this with proactive auth disabled?
>

It's with as much of the defaults as is possible.

Just unzipped a clean download of CR3, added the dummy activation code to
standalone.xml, which is:

<security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
</security-domain>

Started WildFly via JBoss tools, then in Java EE 7 samples project removed
all modules in pom.xml except the JASPIC and support ones:

    <modules>
      <module>test-utils</module>
      <module>jaspic</module>
      <module>util</module>
    </modules>

Then in the root of the Java EE 7 project executed the following command:

mvn --fail-at-end test

So this is with all defaults, which I guess is true (enabled) then for what
you call "proactive" according to this commit:

https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389

Kind regards,
Arjan Tijms













>
>
> Stuart
>
> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone well,
>> since the behaviour is back to that of WildFly 9.
>>
>> Meaning, most tests from the EE 7 samples now pass again, but calling of
>> secureResponse (which 5298 was supposed to fix I think) now fails again:
>>
>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>> SAM method secureResponse not called, but should have been.
>>
>>
>> The JSF includes still fail too, but those were failing in WildFly 9 as
>> well:
>>
>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>> Response did not contain output from JSF view that SAM included.
>>
>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>> Response did not contain output from JSF view that SAM included.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Sorry to ask again, but any news on this topic yet?
>>>
>>> If there's anything I can do to help just let me know.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>> > tests against the latest nightly?
>>> >
>>> > Kind regards,
>>> > Arjan Tijms
>>> >
>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>> >> <stuart.w.douglas at gmail.com> wrote:
>>> >>> Can you verify that this PR:
>>> https://github.com/wildfly/wildfly/pull/8204
>>> >>> fixes your issues?
>>> >>
>>> >> I did a quick test run, but now really everything breaks.
>>> >>
>>> >> In UndertowDeploymentInfoService the following line occurs:
>>> >>
>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>> >>
>>> >> But the constructor arguments are reversed.
>>> >>
>>> >> The arguments are defined as:
>>> >>
>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>> >> final String configuredAuthMethod) {
>>> >>
>>> >> When I reverse the arguments to their correct order, the same tests as
>>> >> before fail unfortunately.
>>> >>
>>> >> This individual case can be rather easily debugged manually by cloning
>>> >> the project using Eclipse/JBoss tools from
>>> >> https://github.com/javaee-samples/javaee7-samples Then importing just
>>> >> the jaspic and test-utils directories as Maven projects, and then
>>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>>> >> server.
>>> >>
>>> >> If you then request:
>>> >>
>>> >>
>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>> >>
>>> >> You should see the same output as:
>>> >>
>>> >>
>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>> >>
>>> >> Hope this helps
>>> >>
>>> >> Kind regards,
>>> >> Arjan Tijms
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> Basically it reverts the recent changes, and instead installs a
>>> handler
>>> >>> after authenticate to handle requests that do not require
>>> authentication.
>>> >>>
>>> >>> Stuart
>>> >>>
>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>> jason.greene at redhat.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> The MIT license also grants the ability to relicense.
>>> >>>>
>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>> stuart.w.douglas at gmail.com>
>>> >>>> wrote:
>>> >>>>
>>> >>>> This was deliberately disabled to match the behavior of EAP6. It
>>> can be
>>> >>>> controlled by the proactive-authentication attribute on the servlet
>>> >>>> container. These JAPIC changes have been driven by this change, in
>>> order to
>>> >>>> get the TCK to pass without proactive auth. I will look into it
>>> today.
>>> >>>>
>>> >>>> If you can contribute your tests it would be greatly appreciated,
>>> we do
>>> >>>> not have much coverage (and apparently neither does the TCK, as it
>>> does not
>>> >>>> pick up these issues). As I understand it if you are the sole
>>> author you
>>> >>>> retain copyright and can re-license them under whatever license you
>>> like.
>>> >>>>
>>> >>>> Stuart
>>> >>>>
>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> >>>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> I discovered some more issues originating from 5298:
>>> >>>>>
>>> >>>>> pre-emptive authentication on a public page doesn't work anymore
>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>> >>>>>
>>> >>>>> This can be easily seen when running the JASPIC tests from
>>> >>>>>
>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>> >>>>>
>>> >>>>> For the basic authentication tests, the following now fail:
>>> >>>>>
>>> >>>>> Failed tests:
>>> >>>>>
>>> >>>>>
>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>> >>>>>
>>> >>>>>
>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>> >>>>>
>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>> >>>>> automatic calling of a SAM at the beginning of a request. After
>>> manual
>>> >>>>> inspection it's clear that the SAM is called, but its outcome is
>>> not
>>> >>>>> being applied.
>>> >>>>>
>>> >>>>> Kind regards,
>>> >>>>> Arjan
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>> arjan.tijms at gmail.com>
>>> >>>>> wrote:
>>> >>>>> > Hi,
>>> >>>>> >
>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>> >>>>> > unfortunately the code is still severely broken now.
>>> >>>>> >
>>> >>>>> > There are two main issues, and they're both in this fragment in
>>> >>>>> > JASPIAuthenticationMechanism:
>>> >>>>> >
>>> >>>>> > if(isValid == null) {
>>> >>>>> >     isValid =
>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>> >>>>> > attachment.getApplicationIdentifier(), new
>>> JBossCallbackHandler());
>>> >>>>> > }
>>> >>>>> >
>>> >>>>> > The first problem is the "isValid == null" check. After the
>>> first call
>>> >>>>> > to request#authenticate in a given request this will always be
>>> >>>>> > non-null. The result is that a request for programmatic
>>> authentication
>>> >>>>> > will effectively be ignored the first time.
>>> >>>>> >
>>> >>>>> > The second problem is that this passes in the
>>> JBossCallbackHandler,
>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and this
>>> will
>>> >>>>> > result in an exception like the following:
>>> >>>>> >
>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>> PBOX00014:
>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not
>>> handle
>>> >>>>> > a callback of type
>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>> >>>>> >     at
>>> >>>>> >
>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>> >>>>> >     at
>>> >>>>> >
>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>> >>>>> >
>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>> >>>>> >
>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of removing
>>> the
>>> >>>>> > "isValid == null" check and passing in the right callback
>>> handler.
>>> >>>>> >
>>> >>>>> > Kind regards,
>>> >>>>> > Arjan Tijms
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>> arjan.tijms at gmail.com>
>>> >>>>> > wrote:
>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>> previous
>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>> everything
>>> >>>>> >> seems to work again. This is a bit of hacky workaround perhaps,
>>> but in
>>> >>>>> >> some quick testing it does do the trick.
>>> >>>>> >>
>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>> arjan.tijms at gmail.com>
>>> >>>>> >> wrote:
>>> >>>>> >>> Hi,
>>> >>>>> >>>
>>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>> >>>>> >>>
>>> >>>>> >>>
>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>> )
>>> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>> >>>>> >>>
>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>> >>>>> >>>
>>> >>>>> >>> There it now obtains the attachment that was set by the new
>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of
>>> the
>>> >>>>> >>> request. And then uses the stored "isValid" outcome directly,
>>> without
>>> >>>>> >>> calling the SAM again.
>>> >>>>> >>>
>>> >>>>> >>> See the code below:
>>> >>>>> >>>
>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>> >>>>> >>>         JASPICAttachment attachment =
>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>> >>>>> >>>
>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>> >>>>> >>>         Account authenticatedAccount = null;
>>> >>>>> >>>
>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>> >>>>> >>>         final ServletRequestContext requestContext =
>>> >>>>> >>> attachment.getRequestContext();
>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>> >>>>> >>> attachment.getSam();
>>> >>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>> >>>>> >>>
>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>> attachment.getMessageInfo();
>>> >>>>> >>>         if (isValid) {
>>> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext, we
>>> need
>>> >>>>> >>> to
>>> >>>>> >>> create an Undertow account based on that
>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>> >>>>> >>> SecurityActions.getSecurityContext();
>>> >>>>> >>>             authenticatedAccount =
>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>> >>>>> >>>         }
>>> >>>>> >>>
>>> >>>>> >>> This is not correct I think. The code should call the SAM once
>>> again
>>> >>>>> >>> and use the outcome from that call.
>>> >>>>> >>>
>>> >>>>> >>> Am I missing something, or was the new call to the SAM simply
>>> >>>>> >>> forgotten at this point?
>>> >>>>> >>>
>>> >>>>> >>> Kind regards,
>>> >>>>> >>> Arjan Tijms
>>> >>>>> _______________________________________________
>>> >>>>> wildfly-dev mailing list
>>> >>>>> wildfly-dev at lists.jboss.org
>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>> wildfly-dev at lists.jboss.org
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/f142f010/attachment-0001.html 

From stuart.w.douglas at gmail.com  Tue Oct 20 20:19:00 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 21 Oct 2015 00:19:00 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
Message-ID: <CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>

I had a quick look into this, and I think your test is invalid.

Basically secureResponse() is called when the message is about to be sent,
in the case of your example this happens when the call stack returns and
the writer is closed. The means that secureResponse can't use the writer,
as it has already been closed. If the test added a header rather than
attempting to use the writer then I think it would work fine.

Even if the writer was not closed and the message was being commited due to
the buffer being full this would still be wrong, as the writer would
basically be writing to some random point in the middle of the stream.

Stuart

On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:

> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Is this with proactive auth disabled?
>>
>
> It's with as much of the defaults as is possible.
>
> Just unzipped a clean download of CR3, added the dummy activation code to
> standalone.xml, which is:
>
> <security-domain name="jaspitest" cache-type="default">
>     <authentication-jaspi>
>         <login-module-stack name="dummy">
>             <login-module code="Dummy" flag="optional"/>
>         </login-module-stack>
>         <auth-module code="Dummy"/>
>     </authentication-jaspi>
> </security-domain>
>
> Started WildFly via JBoss tools, then in Java EE 7 samples project removed
> all modules in pom.xml except the JASPIC and support ones:
>
>     <modules>
>       <module>test-utils</module>
>       <module>jaspic</module>
>       <module>util</module>
>     </modules>
>
> Then in the root of the Java EE 7 project executed the following command:
>
> mvn --fail-at-end test
>
> So this is with all defaults, which I guess is true (enabled) then for
> what you call "proactive" according to this commit:
>
>
> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>>
>> Stuart
>>
>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone well,
>>> since the behaviour is back to that of WildFly 9.
>>>
>>> Meaning, most tests from the EE 7 samples now pass again, but calling of
>>> secureResponse (which 5298 was supposed to fix I think) now fails again:
>>>
>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>> SAM method secureResponse not called, but should have been.
>>>
>>>
>>> The JSF includes still fail too, but those were failing in WildFly 9 as
>>> well:
>>>
>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>> Response did not contain output from JSF view that SAM included.
>>>
>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>> Response did not contain output from JSF view that SAM included.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Sorry to ask again, but any news on this topic yet?
>>>>
>>>> If there's anything I can do to help just let me know.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>> > tests against the latest nightly?
>>>> >
>>>> > Kind regards,
>>>> > Arjan Tijms
>>>> >
>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>> >> Hi,
>>>> >>
>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>> >>> Can you verify that this PR:
>>>> https://github.com/wildfly/wildfly/pull/8204
>>>> >>> fixes your issues?
>>>> >>
>>>> >> I did a quick test run, but now really everything breaks.
>>>> >>
>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>> >>
>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>> >>
>>>> >> But the constructor arguments are reversed.
>>>> >>
>>>> >> The arguments are defined as:
>>>> >>
>>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>>> >> final String configuredAuthMethod) {
>>>> >>
>>>> >> When I reverse the arguments to their correct order, the same tests
>>>> as
>>>> >> before fail unfortunately.
>>>> >>
>>>> >> This individual case can be rather easily debugged manually by
>>>> cloning
>>>> >> the project using Eclipse/JBoss tools from
>>>> >> https://github.com/javaee-samples/javaee7-samples Then importing
>>>> just
>>>> >> the jaspic and test-utils directories as Maven projects, and then
>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>>>> >> server.
>>>> >>
>>>> >> If you then request:
>>>> >>
>>>> >>
>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>> >>
>>>> >> You should see the same output as:
>>>> >>
>>>> >>
>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>> >>
>>>> >> Hope this helps
>>>> >>
>>>> >> Kind regards,
>>>> >> Arjan Tijms
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>>
>>>> >>> Basically it reverts the recent changes, and instead installs a
>>>> handler
>>>> >>> after authenticate to handle requests that do not require
>>>> authentication.
>>>> >>>
>>>> >>> Stuart
>>>> >>>
>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>> jason.greene at redhat.com>
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> The MIT license also grants the ability to relicense.
>>>> >>>>
>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com>
>>>> >>>> wrote:
>>>> >>>>
>>>> >>>> This was deliberately disabled to match the behavior of EAP6. It
>>>> can be
>>>> >>>> controlled by the proactive-authentication attribute on the servlet
>>>> >>>> container. These JAPIC changes have been driven by this change, in
>>>> order to
>>>> >>>> get the TCK to pass without proactive auth. I will look into it
>>>> today.
>>>> >>>>
>>>> >>>> If you can contribute your tests it would be greatly appreciated,
>>>> we do
>>>> >>>> not have much coverage (and apparently neither does the TCK, as it
>>>> does not
>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>> author you
>>>> >>>> retain copyright and can re-license them under whatever license
>>>> you like.
>>>> >>>>
>>>> >>>> Stuart
>>>> >>>>
>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>> >>>>>
>>>> >>>>> Hi,
>>>> >>>>>
>>>> >>>>> I discovered some more issues originating from 5298:
>>>> >>>>>
>>>> >>>>> pre-emptive authentication on a public page doesn't work anymore
>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>> >>>>>
>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>> >>>>>
>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>> >>>>>
>>>> >>>>> For the basic authentication tests, the following now fail:
>>>> >>>>>
>>>> >>>>> Failed tests:
>>>> >>>>>
>>>> >>>>>
>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>> >>>>>
>>>> >>>>>
>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>> >>>>>
>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>> >>>>> automatic calling of a SAM at the beginning of a request. After
>>>> manual
>>>> >>>>> inspection it's clear that the SAM is called, but its outcome is
>>>> not
>>>> >>>>> being applied.
>>>> >>>>>
>>>> >>>>> Kind regards,
>>>> >>>>> Arjan
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>> arjan.tijms at gmail.com>
>>>> >>>>> wrote:
>>>> >>>>> > Hi,
>>>> >>>>> >
>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>> >>>>> > unfortunately the code is still severely broken now.
>>>> >>>>> >
>>>> >>>>> > There are two main issues, and they're both in this fragment in
>>>> >>>>> > JASPIAuthenticationMechanism:
>>>> >>>>> >
>>>> >>>>> > if(isValid == null) {
>>>> >>>>> >     isValid =
>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>> JBossCallbackHandler());
>>>> >>>>> > }
>>>> >>>>> >
>>>> >>>>> > The first problem is the "isValid == null" check. After the
>>>> first call
>>>> >>>>> > to request#authenticate in a given request this will always be
>>>> >>>>> > non-null. The result is that a request for programmatic
>>>> authentication
>>>> >>>>> > will effectively be ignored the first time.
>>>> >>>>> >
>>>> >>>>> > The second problem is that this passes in the
>>>> JBossCallbackHandler,
>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and this
>>>> will
>>>> >>>>> > result in an exception like the following:
>>>> >>>>> >
>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>> PBOX00014:
>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not
>>>> handle
>>>> >>>>> > a callback of type
>>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>> >>>>> >     at
>>>> >>>>> >
>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>> >>>>> >     at
>>>> >>>>> >
>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>> >>>>> >
>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>> >>>>> >
>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of removing
>>>> the
>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>> handler.
>>>> >>>>> >
>>>> >>>>> > Kind regards,
>>>> >>>>> > Arjan Tijms
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> >
>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>> arjan.tijms at gmail.com>
>>>> >>>>> > wrote:
>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>> previous
>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>>> everything
>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>> perhaps, but in
>>>> >>>>> >> some quick testing it does do the trick.
>>>> >>>>> >>
>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>> arjan.tijms at gmail.com>
>>>> >>>>> >> wrote:
>>>> >>>>> >>> Hi,
>>>> >>>>> >>>
>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>>> >>>>> >>>
>>>> >>>>> >>>
>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>> )
>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>>> >>>>> >>>
>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>> >>>>> >>>
>>>> >>>>> >>> There it now obtains the attachment that was set by the new
>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of
>>>> the
>>>> >>>>> >>> request. And then uses the stored "isValid" outcome directly,
>>>> without
>>>> >>>>> >>> calling the SAM again.
>>>> >>>>> >>>
>>>> >>>>> >>> See the code below:
>>>> >>>>> >>>
>>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>> >>>>> >>>         JASPICAttachment attachment =
>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>> >>>>> >>>
>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>> >>>>> >>>
>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>> >>>>> >>> attachment.getRequestContext();
>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>> >>>>> >>> attachment.getSam();
>>>> >>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>>> >>>>> >>>
>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>> attachment.getMessageInfo();
>>>> >>>>> >>>         if (isValid) {
>>>> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext,
>>>> we need
>>>> >>>>> >>> to
>>>> >>>>> >>> create an Undertow account based on that
>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>> >>>>> >>>             authenticatedAccount =
>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>> >>>>> >>>         }
>>>> >>>>> >>>
>>>> >>>>> >>> This is not correct I think. The code should call the SAM
>>>> once again
>>>> >>>>> >>> and use the outcome from that call.
>>>> >>>>> >>>
>>>> >>>>> >>> Am I missing something, or was the new call to the SAM simply
>>>> >>>>> >>> forgotten at this point?
>>>> >>>>> >>>
>>>> >>>>> >>> Kind regards,
>>>> >>>>> >>> Arjan Tijms
>>>> >>>>> _______________________________________________
>>>> >>>>> wildfly-dev mailing list
>>>> >>>>> wildfly-dev at lists.jboss.org
>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> wildfly-dev mailing list
>>>> >>>> wildfly-dev at lists.jboss.org
>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/ca79fc07/attachment-0001.html 

From arjan.tijms at gmail.com  Wed Oct 21 03:24:39 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 21 Oct 2015 09:24:39 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
Message-ID: <CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>

Hi,

On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> I had a quick look into this, and I think your test is invalid.
>
> Basically secureResponse() is called when the message is about to be sent,
> in the case of your example this happens when the call stack returns and
> the writer is closed. The means that secureResponse can't use the writer,
> as it has already been closed.
>

To be 100% sure, I'll verify this with the sped lead, Ron Monzillo. Indeed,
I noticed earlier that Undertow was unable to write to the response at that
point. You're right that the test isn't fully clear on this, and I already
wanted to split it up in a "secureResponse called" (tested via some other
method) and "able to write to the response from secureResponse".

My feeling says Undertow should not have closed the writer at this point
and writing to the response should be possible. It's what the RI allows and
what each and every other server including JBoss EAP 6 allows.



> Even if the writer was not closed and the message was being commited due
> to the buffer being full this would still be wrong, as the writer would
> basically be writing to some random point in the middle of the stream.
>

I'm not sure this is correct. secureResponse is not called whenever the
buffer is full, but only after the (Servlet) resource has been invoked
(meaning, after the target Servlet has executed and control returns from
the last Filter).

One usecase for this is capturing the response fully via a wrapped
response, and then in secureResponse, well, securing this in some way
(perhaps encrypting it). As such it's quite like how a GZIP filter
functions. Clearly the SAM has to be able to write to the response at that
point.

As said, to be 100% sure I'll verify this with Ron.

Kind regards,
Arjan Tijms





>
> Stuart
>
> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> Is this with proactive auth disabled?
>>>
>>
>> It's with as much of the defaults as is possible.
>>
>> Just unzipped a clean download of CR3, added the dummy activation code to
>> standalone.xml, which is:
>>
>> <security-domain name="jaspitest" cache-type="default">
>>     <authentication-jaspi>
>>         <login-module-stack name="dummy">
>>             <login-module code="Dummy" flag="optional"/>
>>         </login-module-stack>
>>         <auth-module code="Dummy"/>
>>     </authentication-jaspi>
>> </security-domain>
>>
>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>> removed all modules in pom.xml except the JASPIC and support ones:
>>
>>     <modules>
>>       <module>test-utils</module>
>>       <module>jaspic</module>
>>       <module>util</module>
>>     </modules>
>>
>> Then in the root of the Java EE 7 project executed the following command:
>>
>> mvn --fail-at-end test
>>
>> So this is with all defaults, which I guess is true (enabled) then for
>> what you call "proactive" according to this commit:
>>
>>
>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Stuart
>>>
>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>> well, since the behaviour is back to that of WildFly 9.
>>>>
>>>> Meaning, most tests from the EE 7 samples now pass again, but calling
>>>> of secureResponse (which 5298 was supposed to fix I think) now fails again:
>>>>
>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>> SAM method secureResponse not called, but should have been.
>>>>
>>>>
>>>> The JSF includes still fail too, but those were failing in WildFly 9 as
>>>> well:
>>>>
>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>> Response did not contain output from JSF view that SAM included.
>>>>
>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>> Response did not contain output from JSF view that SAM included.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>
>>>>> If there's anything I can do to help just let me know.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>>> > tests against the latest nightly?
>>>>> >
>>>>> > Kind regards,
>>>>> > Arjan Tijms
>>>>> >
>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>> >> Hi,
>>>>> >>
>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>> >>> Can you verify that this PR:
>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>> >>> fixes your issues?
>>>>> >>
>>>>> >> I did a quick test run, but now really everything breaks.
>>>>> >>
>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>> >>
>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>> >>
>>>>> >> But the constructor arguments are reversed.
>>>>> >>
>>>>> >> The arguments are defined as:
>>>>> >>
>>>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>>>> >> final String configuredAuthMethod) {
>>>>> >>
>>>>> >> When I reverse the arguments to their correct order, the same tests
>>>>> as
>>>>> >> before fail unfortunately.
>>>>> >>
>>>>> >> This individual case can be rather easily debugged manually by
>>>>> cloning
>>>>> >> the project using Eclipse/JBoss tools from
>>>>> >> https://github.com/javaee-samples/javaee7-samples Then importing
>>>>> just
>>>>> >> the jaspic and test-utils directories as Maven projects, and then
>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>>>>> >> server.
>>>>> >>
>>>>> >> If you then request:
>>>>> >>
>>>>> >>
>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>> >>
>>>>> >> You should see the same output as:
>>>>> >>
>>>>> >>
>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>> >>
>>>>> >> Hope this helps
>>>>> >>
>>>>> >> Kind regards,
>>>>> >> Arjan Tijms
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> Basically it reverts the recent changes, and instead installs a
>>>>> handler
>>>>> >>> after authenticate to handle requests that do not require
>>>>> authentication.
>>>>> >>>
>>>>> >>> Stuart
>>>>> >>>
>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>> jason.greene at redhat.com>
>>>>> >>> wrote:
>>>>> >>>>
>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>> >>>>
>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>> stuart.w.douglas at gmail.com>
>>>>> >>>> wrote:
>>>>> >>>>
>>>>> >>>> This was deliberately disabled to match the behavior of EAP6. It
>>>>> can be
>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>> servlet
>>>>> >>>> container. These JAPIC changes have been driven by this change,
>>>>> in order to
>>>>> >>>> get the TCK to pass without proactive auth. I will look into it
>>>>> today.
>>>>> >>>>
>>>>> >>>> If you can contribute your tests it would be greatly appreciated,
>>>>> we do
>>>>> >>>> not have much coverage (and apparently neither does the TCK, as
>>>>> it does not
>>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>>> author you
>>>>> >>>> retain copyright and can re-license them under whatever license
>>>>> you like.
>>>>> >>>>
>>>>> >>>> Stuart
>>>>> >>>>
>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> Hi,
>>>>> >>>>>
>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>> >>>>>
>>>>> >>>>> pre-emptive authentication on a public page doesn't work anymore
>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>> >>>>>
>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>> >>>>>
>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>> >>>>>
>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>> >>>>>
>>>>> >>>>> Failed tests:
>>>>> >>>>>
>>>>> >>>>>
>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>> >>>>>
>>>>> >>>>>
>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>> >>>>>
>>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>>> >>>>> automatic calling of a SAM at the beginning of a request. After
>>>>> manual
>>>>> >>>>> inspection it's clear that the SAM is called, but its outcome is
>>>>> not
>>>>> >>>>> being applied.
>>>>> >>>>>
>>>>> >>>>> Kind regards,
>>>>> >>>>> Arjan
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>> arjan.tijms at gmail.com>
>>>>> >>>>> wrote:
>>>>> >>>>> > Hi,
>>>>> >>>>> >
>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>> >>>>> >
>>>>> >>>>> > There are two main issues, and they're both in this fragment in
>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>> >>>>> >
>>>>> >>>>> > if(isValid == null) {
>>>>> >>>>> >     isValid =
>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>> JBossCallbackHandler());
>>>>> >>>>> > }
>>>>> >>>>> >
>>>>> >>>>> > The first problem is the "isValid == null" check. After the
>>>>> first call
>>>>> >>>>> > to request#authenticate in a given request this will always be
>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>> authentication
>>>>> >>>>> > will effectively be ignored the first time.
>>>>> >>>>> >
>>>>> >>>>> > The second problem is that this passes in the
>>>>> JBossCallbackHandler,
>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and this
>>>>> will
>>>>> >>>>> > result in an exception like the following:
>>>>> >>>>> >
>>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>>> PBOX00014:
>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not
>>>>> handle
>>>>> >>>>> > a callback of type
>>>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>>> >>>>> >     at
>>>>> >>>>> >
>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>> >>>>> >     at
>>>>> >>>>> >
>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>> >>>>> >
>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>> >>>>> >
>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of removing
>>>>> the
>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>> handler.
>>>>> >>>>> >
>>>>> >>>>> > Kind regards,
>>>>> >>>>> > Arjan Tijms
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> >
>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>> arjan.tijms at gmail.com>
>>>>> >>>>> > wrote:
>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>>> previous
>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>>>> everything
>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>> perhaps, but in
>>>>> >>>>> >> some quick testing it does do the trick.
>>>>> >>>>> >>
>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>> arjan.tijms at gmail.com>
>>>>> >>>>> >> wrote:
>>>>> >>>>> >>> Hi,
>>>>> >>>>> >>>
>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>>>> >>>>> >>>
>>>>> >>>>> >>>
>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>> )
>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>>>> >>>>> >>>
>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>> >>>>> >>>
>>>>> >>>>> >>> There it now obtains the attachment that was set by the new
>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning
>>>>> of the
>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>> directly, without
>>>>> >>>>> >>> calling the SAM again.
>>>>> >>>>> >>>
>>>>> >>>>> >>> See the code below:
>>>>> >>>>> >>>
>>>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>> >>>>> >>>
>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>> >>>>> >>>
>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>> >>>>> >>> attachment.getRequestContext();
>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>> >>>>> >>> attachment.getSam();
>>>>> >>>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>>>> >>>>> >>>
>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>> attachment.getMessageInfo();
>>>>> >>>>> >>>         if (isValid) {
>>>>> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext,
>>>>> we need
>>>>> >>>>> >>> to
>>>>> >>>>> >>> create an Undertow account based on that
>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>> >>>>> >>>             authenticatedAccount =
>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>> >>>>> >>>         }
>>>>> >>>>> >>>
>>>>> >>>>> >>> This is not correct I think. The code should call the SAM
>>>>> once again
>>>>> >>>>> >>> and use the outcome from that call.
>>>>> >>>>> >>>
>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM simply
>>>>> >>>>> >>> forgotten at this point?
>>>>> >>>>> >>>
>>>>> >>>>> >>> Kind regards,
>>>>> >>>>> >>> Arjan Tijms
>>>>> >>>>> _______________________________________________
>>>>> >>>>> wildfly-dev mailing list
>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> wildfly-dev mailing list
>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/7cc7a7d2/attachment-0001.html 

From stuart.w.douglas at gmail.com  Wed Oct 21 04:04:23 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 21 Oct 2015 08:04:23 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
	<CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
Message-ID: <CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>

Ah, I just re-read the spec and we are invoking this in the wrong place, it
should be invoked on call stack return like you say, and not on response
commit. The spec explicitly states that this may be called after the
response has already been commited, but recommends a SAM buffer the full
response using a HttpServletResponseWrapper if this is a problem (section
B.9 ).

Stuart

On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> I had a quick look into this, and I think your test is invalid.
>>
>> Basically secureResponse() is called when the message is about to be
>> sent, in the case of your example this happens when the call stack returns
>> and the writer is closed. The means that secureResponse can't use the
>> writer, as it has already been closed.
>>
>
> To be 100% sure, I'll verify this with the sped lead, Ron Monzillo.
> Indeed, I noticed earlier that Undertow was unable to write to the response
> at that point. You're right that the test isn't fully clear on this, and I
> already wanted to split it up in a "secureResponse called" (tested via some
> other method) and "able to write to the response from secureResponse".
>
> My feeling says Undertow should not have closed the writer at this point
> and writing to the response should be possible. It's what the RI allows and
> what each and every other server including JBoss EAP 6 allows.
>
>
>
>> Even if the writer was not closed and the message was being commited due
>> to the buffer being full this would still be wrong, as the writer would
>> basically be writing to some random point in the middle of the stream.
>>
>
> I'm not sure this is correct. secureResponse is not called whenever the
> buffer is full, but only after the (Servlet) resource has been invoked
> (meaning, after the target Servlet has executed and control returns from
> the last Filter).
>
> One usecase for this is capturing the response fully via a wrapped
> response, and then in secureResponse, well, securing this in some way
> (perhaps encrypting it). As such it's quite like how a GZIP filter
> functions. Clearly the SAM has to be able to write to the response at that
> point.
>
> As said, to be 100% sure I'll verify this with Ron.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>>
>> Stuart
>>
>> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>>> stuart.w.douglas at gmail.com> wrote:
>>>
>>>> Is this with proactive auth disabled?
>>>>
>>>
>>> It's with as much of the defaults as is possible.
>>>
>>> Just unzipped a clean download of CR3, added the dummy activation code
>>> to standalone.xml, which is:
>>>
>>> <security-domain name="jaspitest" cache-type="default">
>>>     <authentication-jaspi>
>>>         <login-module-stack name="dummy">
>>>             <login-module code="Dummy" flag="optional"/>
>>>         </login-module-stack>
>>>         <auth-module code="Dummy"/>
>>>     </authentication-jaspi>
>>> </security-domain>
>>>
>>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>>> removed all modules in pom.xml except the JASPIC and support ones:
>>>
>>>     <modules>
>>>       <module>test-utils</module>
>>>       <module>jaspic</module>
>>>       <module>util</module>
>>>     </modules>
>>>
>>> Then in the root of the Java EE 7 project executed the following command:
>>>
>>> mvn --fail-at-end test
>>>
>>> So this is with all defaults, which I guess is true (enabled) then for
>>> what you call "proactive" according to this commit:
>>>
>>>
>>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Stuart
>>>>
>>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>>> well, since the behaviour is back to that of WildFly 9.
>>>>>
>>>>> Meaning, most tests from the EE 7 samples now pass again, but calling
>>>>> of secureResponse (which 5298 was supposed to fix I think) now fails again:
>>>>>
>>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>>> SAM method secureResponse not called, but should have been.
>>>>>
>>>>>
>>>>> The JSF includes still fail too, but those were failing in WildFly 9
>>>>> as well:
>>>>>
>>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>>> Response did not contain output from JSF view that SAM included.
>>>>>
>>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>>> Response did not contain output from JSF view that SAM included.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>>
>>>>>> If there's anything I can do to help just let me know.
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>>>> > tests against the latest nightly?
>>>>>> >
>>>>>> > Kind regards,
>>>>>> > Arjan Tijms
>>>>>> >
>>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>> >> Hi,
>>>>>> >>
>>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>>> >>> Can you verify that this PR:
>>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>>> >>> fixes your issues?
>>>>>> >>
>>>>>> >> I did a quick test run, but now really everything breaks.
>>>>>> >>
>>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>>> >>
>>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>>> >>
>>>>>> >> But the constructor arguments are reversed.
>>>>>> >>
>>>>>> >> The arguments are defined as:
>>>>>> >>
>>>>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>>>>> >> final String configuredAuthMethod) {
>>>>>> >>
>>>>>> >> When I reverse the arguments to their correct order, the same
>>>>>> tests as
>>>>>> >> before fail unfortunately.
>>>>>> >>
>>>>>> >> This individual case can be rather easily debugged manually by
>>>>>> cloning
>>>>>> >> the project using Eclipse/JBoss tools from
>>>>>> >> https://github.com/javaee-samples/javaee7-samples Then importing
>>>>>> just
>>>>>> >> the jaspic and test-utils directories as Maven projects, and then
>>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on the
>>>>>> >> server.
>>>>>> >>
>>>>>> >> If you then request:
>>>>>> >>
>>>>>> >>
>>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>>> >>
>>>>>> >> You should see the same output as:
>>>>>> >>
>>>>>> >>
>>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>>> >>
>>>>>> >> Hope this helps
>>>>>> >>
>>>>>> >> Kind regards,
>>>>>> >> Arjan Tijms
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>>
>>>>>> >>> Basically it reverts the recent changes, and instead installs a
>>>>>> handler
>>>>>> >>> after authenticate to handle requests that do not require
>>>>>> authentication.
>>>>>> >>>
>>>>>> >>> Stuart
>>>>>> >>>
>>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>>> jason.greene at redhat.com>
>>>>>> >>> wrote:
>>>>>> >>>>
>>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>>> >>>>
>>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>>> stuart.w.douglas at gmail.com>
>>>>>> >>>> wrote:
>>>>>> >>>>
>>>>>> >>>> This was deliberately disabled to match the behavior of EAP6. It
>>>>>> can be
>>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>>> servlet
>>>>>> >>>> container. These JAPIC changes have been driven by this change,
>>>>>> in order to
>>>>>> >>>> get the TCK to pass without proactive auth. I will look into it
>>>>>> today.
>>>>>> >>>>
>>>>>> >>>> If you can contribute your tests it would be greatly
>>>>>> appreciated, we do
>>>>>> >>>> not have much coverage (and apparently neither does the TCK, as
>>>>>> it does not
>>>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>>>> author you
>>>>>> >>>> retain copyright and can re-license them under whatever license
>>>>>> you like.
>>>>>> >>>>
>>>>>> >>>> Stuart
>>>>>> >>>>
>>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> Hi,
>>>>>> >>>>>
>>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>>> >>>>>
>>>>>> >>>>> pre-emptive authentication on a public page doesn't work anymore
>>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>> >>>>>
>>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>>> >>>>>
>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>> >>>>>
>>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>>> >>>>>
>>>>>> >>>>> Failed tests:
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>> >>>>>
>>>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>>>> >>>>> automatic calling of a SAM at the beginning of a request. After
>>>>>> manual
>>>>>> >>>>> inspection it's clear that the SAM is called, but its outcome
>>>>>> is not
>>>>>> >>>>> being applied.
>>>>>> >>>>>
>>>>>> >>>>> Kind regards,
>>>>>> >>>>> Arjan
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>>> arjan.tijms at gmail.com>
>>>>>> >>>>> wrote:
>>>>>> >>>>> > Hi,
>>>>>> >>>>> >
>>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>>> >>>>> >
>>>>>> >>>>> > There are two main issues, and they're both in this fragment
>>>>>> in
>>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>>> >>>>> >
>>>>>> >>>>> > if(isValid == null) {
>>>>>> >>>>> >     isValid =
>>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>>> JBossCallbackHandler());
>>>>>> >>>>> > }
>>>>>> >>>>> >
>>>>>> >>>>> > The first problem is the "isValid == null" check. After the
>>>>>> first call
>>>>>> >>>>> > to request#authenticate in a given request this will always be
>>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>>> authentication
>>>>>> >>>>> > will effectively be ignored the first time.
>>>>>> >>>>> >
>>>>>> >>>>> > The second problem is that this passes in the
>>>>>> JBossCallbackHandler,
>>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and this
>>>>>> will
>>>>>> >>>>> > result in an exception like the following:
>>>>>> >>>>> >
>>>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>>>> PBOX00014:
>>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does
>>>>>> not handle
>>>>>> >>>>> > a callback of type
>>>>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>>>> >>>>> >     at
>>>>>> >>>>> >
>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>>> >>>>> >     at
>>>>>> >>>>> >
>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>>> >>>>> >
>>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>>> >>>>> >
>>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of
>>>>>> removing the
>>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>>> handler.
>>>>>> >>>>> >
>>>>>> >>>>> > Kind regards,
>>>>>> >>>>> > Arjan Tijms
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> >
>>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>>> arjan.tijms at gmail.com>
>>>>>> >>>>> > wrote:
>>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>>>> previous
>>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>>>>> everything
>>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>>> perhaps, but in
>>>>>> >>>>> >> some quick testing it does do the trick.
>>>>>> >>>>> >>
>>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>>> arjan.tijms at gmail.com>
>>>>>> >>>>> >> wrote:
>>>>>> >>>>> >>> Hi,
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>>>>> >>>>> >>>
>>>>>> >>>>> >>>
>>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>>> )
>>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> There it now obtains the attachment that was set by the new
>>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning
>>>>>> of the
>>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>>> directly, without
>>>>>> >>>>> >>> calling the SAM again.
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> See the code below:
>>>>>> >>>>> >>>
>>>>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>>> >>>>> >>>
>>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>>> >>>>> >>>
>>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>>> >>>>> >>> attachment.getRequestContext();
>>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>>> >>>>> >>> attachment.getSam();
>>>>>> >>>>> >>>         final JASPICallbackHandler cbh =
>>>>>> attachment.getCbh();
>>>>>> >>>>> >>>
>>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>>> attachment.getMessageInfo();
>>>>>> >>>>> >>>         if (isValid) {
>>>>>> >>>>> >>>             // The CBH filled in the JBOSS SecurityContext,
>>>>>> we need
>>>>>> >>>>> >>> to
>>>>>> >>>>> >>> create an Undertow account based on that
>>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>>> >>>>> >>>             authenticatedAccount =
>>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>>> >>>>> >>>         }
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> This is not correct I think. The code should call the SAM
>>>>>> once again
>>>>>> >>>>> >>> and use the outcome from that call.
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM
>>>>>> simply
>>>>>> >>>>> >>> forgotten at this point?
>>>>>> >>>>> >>>
>>>>>> >>>>> >>> Kind regards,
>>>>>> >>>>> >>> Arjan Tijms
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> wildfly-dev mailing list
>>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>> >>>>
>>>>>> >>>> _______________________________________________
>>>>>> >>>> wildfly-dev mailing list
>>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/184c2938/attachment-0001.html 

From arjan.tijms at gmail.com  Wed Oct 21 04:51:03 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 21 Oct 2015 10:51:03 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
	<CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
	<CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>
Message-ID: <CAE=-AhB7W3=Y_=qWCoT4-JQmiA8FRCNB_MuTGyEWzXaBpdg8sg@mail.gmail.com>

On Wed, Oct 21, 2015 at 10:04 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> Ah, I just re-read the spec and we are invoking this in the wrong place,
> it should be invoked on call stack return like you say, and not on response
> commit. The spec explicitly states that this may be called after the
> response has already been commited, but recommends a SAM buffer the full
> response using a HttpServletResponseWrapper if this is a problem (section
> B.9 ).
>

Okay, great to hear it's more clear now ;)




>
> Stuart
>
>
> On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> I had a quick look into this, and I think your test is invalid.
>>>
>>> Basically secureResponse() is called when the message is about to be
>>> sent, in the case of your example this happens when the call stack returns
>>> and the writer is closed. The means that secureResponse can't use the
>>> writer, as it has already been closed.
>>>
>>
>> To be 100% sure, I'll verify this with the sped lead, Ron Monzillo.
>> Indeed, I noticed earlier that Undertow was unable to write to the response
>> at that point. You're right that the test isn't fully clear on this, and I
>> already wanted to split it up in a "secureResponse called" (tested via some
>> other method) and "able to write to the response from secureResponse".
>>
>> My feeling says Undertow should not have closed the writer at this point
>> and writing to the response should be possible. It's what the RI allows and
>> what each and every other server including JBoss EAP 6 allows.
>>
>>
>>
>>> Even if the writer was not closed and the message was being commited due
>>> to the buffer being full this would still be wrong, as the writer would
>>> basically be writing to some random point in the middle of the stream.
>>>
>>
>> I'm not sure this is correct. secureResponse is not called whenever the
>> buffer is full, but only after the (Servlet) resource has been invoked
>> (meaning, after the target Servlet has executed and control returns from
>> the last Filter).
>>
>> One usecase for this is capturing the response fully via a wrapped
>> response, and then in secureResponse, well, securing this in some way
>> (perhaps encrypting it). As such it's quite like how a GZIP filter
>> functions. Clearly the SAM has to be able to write to the response at that
>> point.
>>
>> As said, to be 100% sure I'll verify this with Ron.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>>
>>> Stuart
>>>
>>> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>
>>>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com> wrote:
>>>>
>>>>> Is this with proactive auth disabled?
>>>>>
>>>>
>>>> It's with as much of the defaults as is possible.
>>>>
>>>> Just unzipped a clean download of CR3, added the dummy activation code
>>>> to standalone.xml, which is:
>>>>
>>>> <security-domain name="jaspitest" cache-type="default">
>>>>     <authentication-jaspi>
>>>>         <login-module-stack name="dummy">
>>>>             <login-module code="Dummy" flag="optional"/>
>>>>         </login-module-stack>
>>>>         <auth-module code="Dummy"/>
>>>>     </authentication-jaspi>
>>>> </security-domain>
>>>>
>>>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>>>> removed all modules in pom.xml except the JASPIC and support ones:
>>>>
>>>>     <modules>
>>>>       <module>test-utils</module>
>>>>       <module>jaspic</module>
>>>>       <module>util</module>
>>>>     </modules>
>>>>
>>>> Then in the root of the Java EE 7 project executed the following
>>>> command:
>>>>
>>>> mvn --fail-at-end test
>>>>
>>>> So this is with all defaults, which I guess is true (enabled) then for
>>>> what you call "proactive" according to this commit:
>>>>
>>>>
>>>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>>>> well, since the behaviour is back to that of WildFly 9.
>>>>>>
>>>>>> Meaning, most tests from the EE 7 samples now pass again, but calling
>>>>>> of secureResponse (which 5298 was supposed to fix I think) now fails again:
>>>>>>
>>>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>>>> SAM method secureResponse not called, but should have been.
>>>>>>
>>>>>>
>>>>>> The JSF includes still fail too, but those were failing in WildFly 9
>>>>>> as well:
>>>>>>
>>>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>
>>>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>>>
>>>>>>> If there's anything I can do to help just let me know.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>>> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>>>>> > tests against the latest nightly?
>>>>>>> >
>>>>>>> > Kind regards,
>>>>>>> > Arjan Tijms
>>>>>>> >
>>>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <
>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>> >> Hi,
>>>>>>> >>
>>>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>>>> >>> Can you verify that this PR:
>>>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>>>> >>> fixes your issues?
>>>>>>> >>
>>>>>>> >> I did a quick test run, but now really everything breaks.
>>>>>>> >>
>>>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>>>> >>
>>>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>>>> >>
>>>>>>> >> But the constructor arguments are reversed.
>>>>>>> >>
>>>>>>> >> The arguments are defined as:
>>>>>>> >>
>>>>>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>>>>>> >> final String configuredAuthMethod) {
>>>>>>> >>
>>>>>>> >> When I reverse the arguments to their correct order, the same
>>>>>>> tests as
>>>>>>> >> before fail unfortunately.
>>>>>>> >>
>>>>>>> >> This individual case can be rather easily debugged manually by
>>>>>>> cloning
>>>>>>> >> the project using Eclipse/JBoss tools from
>>>>>>> >> https://github.com/javaee-samples/javaee7-samples Then importing
>>>>>>> just
>>>>>>> >> the jaspic and test-utils directories as Maven projects, and then
>>>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on
>>>>>>> the
>>>>>>> >> server.
>>>>>>> >>
>>>>>>> >> If you then request:
>>>>>>> >>
>>>>>>> >>
>>>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>>>> >>
>>>>>>> >> You should see the same output as:
>>>>>>> >>
>>>>>>> >>
>>>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>>>> >>
>>>>>>> >> Hope this helps
>>>>>>> >>
>>>>>>> >> Kind regards,
>>>>>>> >> Arjan Tijms
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>>
>>>>>>> >>> Basically it reverts the recent changes, and instead installs a
>>>>>>> handler
>>>>>>> >>> after authenticate to handle requests that do not require
>>>>>>> authentication.
>>>>>>> >>>
>>>>>>> >>> Stuart
>>>>>>> >>>
>>>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>>>> jason.greene at redhat.com>
>>>>>>> >>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>>>> >>>>
>>>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>>>> stuart.w.douglas at gmail.com>
>>>>>>> >>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> This was deliberately disabled to match the behavior of EAP6.
>>>>>>> It can be
>>>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>>>> servlet
>>>>>>> >>>> container. These JAPIC changes have been driven by this change,
>>>>>>> in order to
>>>>>>> >>>> get the TCK to pass without proactive auth. I will look into it
>>>>>>> today.
>>>>>>> >>>>
>>>>>>> >>>> If you can contribute your tests it would be greatly
>>>>>>> appreciated, we do
>>>>>>> >>>> not have much coverage (and apparently neither does the TCK, as
>>>>>>> it does not
>>>>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>>>>> author you
>>>>>>> >>>> retain copyright and can re-license them under whatever license
>>>>>>> you like.
>>>>>>> >>>>
>>>>>>> >>>> Stuart
>>>>>>> >>>>
>>>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com>
>>>>>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> Hi,
>>>>>>> >>>>>
>>>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>>>> >>>>>
>>>>>>> >>>>> pre-emptive authentication on a public page doesn't work
>>>>>>> anymore
>>>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>>> >>>>>
>>>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>>>> >>>>>
>>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>>> >>>>>
>>>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>>>> >>>>>
>>>>>>> >>>>> Failed tests:
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>> >>>>>
>>>>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>>>>> >>>>> automatic calling of a SAM at the beginning of a request.
>>>>>>> After manual
>>>>>>> >>>>> inspection it's clear that the SAM is called, but its outcome
>>>>>>> is not
>>>>>>> >>>>> being applied.
>>>>>>> >>>>>
>>>>>>> >>>>> Kind regards,
>>>>>>> >>>>> Arjan
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>>>> arjan.tijms at gmail.com>
>>>>>>> >>>>> wrote:
>>>>>>> >>>>> > Hi,
>>>>>>> >>>>> >
>>>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>>>> >>>>> >
>>>>>>> >>>>> > There are two main issues, and they're both in this fragment
>>>>>>> in
>>>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>>>> >>>>> >
>>>>>>> >>>>> > if(isValid == null) {
>>>>>>> >>>>> >     isValid =
>>>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>>>> JBossCallbackHandler());
>>>>>>> >>>>> > }
>>>>>>> >>>>> >
>>>>>>> >>>>> > The first problem is the "isValid == null" check. After the
>>>>>>> first call
>>>>>>> >>>>> > to request#authenticate in a given request this will always
>>>>>>> be
>>>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>>>> authentication
>>>>>>> >>>>> > will effectively be ignored the first time.
>>>>>>> >>>>> >
>>>>>>> >>>>> > The second problem is that this passes in the
>>>>>>> JBossCallbackHandler,
>>>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and
>>>>>>> this will
>>>>>>> >>>>> > result in an exception like the following:
>>>>>>> >>>>> >
>>>>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>>>>> PBOX00014:
>>>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does
>>>>>>> not handle
>>>>>>> >>>>> > a callback of type
>>>>>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>>>>> >>>>> >     at
>>>>>>> >>>>> >
>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>>>> >>>>> >     at
>>>>>>> >>>>> >
>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>>>> >>>>> >
>>>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>>>> >>>>> >
>>>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of
>>>>>>> removing the
>>>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>>>> handler.
>>>>>>> >>>>> >
>>>>>>> >>>>> > Kind regards,
>>>>>>> >>>>> > Arjan Tijms
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> >
>>>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>>>> arjan.tijms at gmail.com>
>>>>>>> >>>>> > wrote:
>>>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>>>>> previous
>>>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>>>>>> everything
>>>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>>>> perhaps, but in
>>>>>>> >>>>> >> some quick testing it does do the trick.
>>>>>>> >>>>> >>
>>>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>>>> arjan.tijms at gmail.com>
>>>>>>> >>>>> >> wrote:
>>>>>>> >>>>> >>> Hi,
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit
>>>>>>> specifically
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>>
>>>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>>>> )
>>>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do
>>>>>>> anything.
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> There it now obtains the attachment that was set by the new
>>>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the beginning
>>>>>>> of the
>>>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>>>> directly, without
>>>>>>> >>>>> >>> calling the SAM again.
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> See the code below:
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>>>> >>>>> >>> attachment.getRequestContext();
>>>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>>>> >>>>> >>> attachment.getSam();
>>>>>>> >>>>> >>>         final JASPICallbackHandler cbh =
>>>>>>> attachment.getCbh();
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>>>> attachment.getMessageInfo();
>>>>>>> >>>>> >>>         if (isValid) {
>>>>>>> >>>>> >>>             // The CBH filled in the JBOSS
>>>>>>> SecurityContext, we need
>>>>>>> >>>>> >>> to
>>>>>>> >>>>> >>> create an Undertow account based on that
>>>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>>>> >>>>> >>>             authenticatedAccount =
>>>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>>>> >>>>> >>>         }
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> This is not correct I think. The code should call the SAM
>>>>>>> once again
>>>>>>> >>>>> >>> and use the outcome from that call.
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM
>>>>>>> simply
>>>>>>> >>>>> >>> forgotten at this point?
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>> Kind regards,
>>>>>>> >>>>> >>> Arjan Tijms
>>>>>>> >>>>> _______________________________________________
>>>>>>> >>>>> wildfly-dev mailing list
>>>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>> >>>>
>>>>>>> >>>> _______________________________________________
>>>>>>> >>>> wildfly-dev mailing list
>>>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/8fdaf1f8/attachment-0001.html 

From stuart.w.douglas at gmail.com  Wed Oct 21 05:46:19 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 21 Oct 2015 09:46:19 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhB7W3=Y_=qWCoT4-JQmiA8FRCNB_MuTGyEWzXaBpdg8sg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
	<CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
	<CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>
	<CAE=-AhB7W3=Y_=qWCoT4-JQmiA8FRCNB_MuTGyEWzXaBpdg8sg@mail.gmail.com>
Message-ID: <CAAoo=c56Tc=dqOF6SO30-DZc6NQ6S2PO4F27_v2=yiFrXx8LCg@mail.gmail.com>

One thing I am still not clear on is how this should work with async
servlet, do you have any ideas?

Normally when a request has returned to the container it means it is done,
however with async requests this is not the case.

Stuart

On Wed, 21 Oct 2015 at 19:51 arjan tijms <arjan.tijms at gmail.com> wrote:

> On Wed, Oct 21, 2015 at 10:04 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> Ah, I just re-read the spec and we are invoking this in the wrong place,
>> it should be invoked on call stack return like you say, and not on response
>> commit. The spec explicitly states that this may be called after the
>> response has already been commited, but recommends a SAM buffer the full
>> response using a HttpServletResponseWrapper if this is a problem (section
>> B.9 ).
>>
>
> Okay, great to hear it's more clear now ;)
>
>
>
>
>>
>> Stuart
>>
>>
>> On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <
>>> stuart.w.douglas at gmail.com> wrote:
>>>
>>>> I had a quick look into this, and I think your test is invalid.
>>>>
>>>> Basically secureResponse() is called when the message is about to be
>>>> sent, in the case of your example this happens when the call stack returns
>>>> and the writer is closed. The means that secureResponse can't use the
>>>> writer, as it has already been closed.
>>>>
>>>
>>> To be 100% sure, I'll verify this with the sped lead, Ron Monzillo.
>>> Indeed, I noticed earlier that Undertow was unable to write to the response
>>> at that point. You're right that the test isn't fully clear on this, and I
>>> already wanted to split it up in a "secureResponse called" (tested via some
>>> other method) and "able to write to the response from secureResponse".
>>>
>>> My feeling says Undertow should not have closed the writer at this point
>>> and writing to the response should be possible. It's what the RI allows and
>>> what each and every other server including JBoss EAP 6 allows.
>>>
>>>
>>>
>>>> Even if the writer was not closed and the message was being commited
>>>> due to the buffer being full this would still be wrong, as the writer would
>>>> basically be writing to some random point in the middle of the stream.
>>>>
>>>
>>> I'm not sure this is correct. secureResponse is not called whenever the
>>> buffer is full, but only after the (Servlet) resource has been invoked
>>> (meaning, after the target Servlet has executed and control returns from
>>> the last Filter).
>>>
>>> One usecase for this is capturing the response fully via a wrapped
>>> response, and then in secureResponse, well, securing this in some way
>>> (perhaps encrypting it). As such it's quite like how a GZIP filter
>>> functions. Clearly the SAM has to be able to write to the response at that
>>> point.
>>>
>>> As said, to be 100% sure I'll verify this with Ron.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Stuart
>>>>
>>>> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>
>>>>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>
>>>>>> Is this with proactive auth disabled?
>>>>>>
>>>>>
>>>>> It's with as much of the defaults as is possible.
>>>>>
>>>>> Just unzipped a clean download of CR3, added the dummy activation code
>>>>> to standalone.xml, which is:
>>>>>
>>>>> <security-domain name="jaspitest" cache-type="default">
>>>>>     <authentication-jaspi>
>>>>>         <login-module-stack name="dummy">
>>>>>             <login-module code="Dummy" flag="optional"/>
>>>>>         </login-module-stack>
>>>>>         <auth-module code="Dummy"/>
>>>>>     </authentication-jaspi>
>>>>> </security-domain>
>>>>>
>>>>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>>>>> removed all modules in pom.xml except the JASPIC and support ones:
>>>>>
>>>>>     <modules>
>>>>>       <module>test-utils</module>
>>>>>       <module>jaspic</module>
>>>>>       <module>util</module>
>>>>>     </modules>
>>>>>
>>>>> Then in the root of the Java EE 7 project executed the following
>>>>> command:
>>>>>
>>>>> mvn --fail-at-end test
>>>>>
>>>>> So this is with all defaults, which I guess is true (enabled) then for
>>>>> what you call "proactive" according to this commit:
>>>>>
>>>>>
>>>>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>>>>> well, since the behaviour is back to that of WildFly 9.
>>>>>>>
>>>>>>> Meaning, most tests from the EE 7 samples now pass again, but
>>>>>>> calling of secureResponse (which 5298 was supposed to fix I think) now
>>>>>>> fails again:
>>>>>>>
>>>>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>>>>> SAM method secureResponse not called, but should have been.
>>>>>>>
>>>>>>>
>>>>>>> The JSF includes still fail too, but those were failing in WildFly 9
>>>>>>> as well:
>>>>>>>
>>>>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>
>>>>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>>>>
>>>>>>>> If there's anything I can do to help just let me know.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>>>>>> > tests against the latest nightly?
>>>>>>>> >
>>>>>>>> > Kind regards,
>>>>>>>> > Arjan Tijms
>>>>>>>> >
>>>>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <
>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>> >> Hi,
>>>>>>>> >>
>>>>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>>>>> >>> Can you verify that this PR:
>>>>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>>>>> >>> fixes your issues?
>>>>>>>> >>
>>>>>>>> >> I did a quick test run, but now really everything breaks.
>>>>>>>> >>
>>>>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>>>>> >>
>>>>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>>>>> >>
>>>>>>>> >> But the constructor arguments are reversed.
>>>>>>>> >>
>>>>>>>> >> The arguments are defined as:
>>>>>>>> >>
>>>>>>>> >>  public JASPIAuthenticationMechanism(final String securityDomain,
>>>>>>>> >> final String configuredAuthMethod) {
>>>>>>>> >>
>>>>>>>> >> When I reverse the arguments to their correct order, the same
>>>>>>>> tests as
>>>>>>>> >> before fail unfortunately.
>>>>>>>> >>
>>>>>>>> >> This individual case can be rather easily debugged manually by
>>>>>>>> cloning
>>>>>>>> >> the project using Eclipse/JBoss tools from
>>>>>>>> >> https://github.com/javaee-samples/javaee7-samples Then
>>>>>>>> importing just
>>>>>>>> >> the jaspic and test-utils directories as Maven projects, and then
>>>>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on
>>>>>>>> the
>>>>>>>> >> server.
>>>>>>>> >>
>>>>>>>> >> If you then request:
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>>>>> >>
>>>>>>>> >> You should see the same output as:
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>>>>> >>
>>>>>>>> >> Hope this helps
>>>>>>>> >>
>>>>>>>> >> Kind regards,
>>>>>>>> >> Arjan Tijms
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>>
>>>>>>>> >>> Basically it reverts the recent changes, and instead installs a
>>>>>>>> handler
>>>>>>>> >>> after authenticate to handle requests that do not require
>>>>>>>> authentication.
>>>>>>>> >>>
>>>>>>>> >>> Stuart
>>>>>>>> >>>
>>>>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>>>>> jason.greene at redhat.com>
>>>>>>>> >>> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>>>>> >>>>
>>>>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>>>>> stuart.w.douglas at gmail.com>
>>>>>>>> >>>> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> This was deliberately disabled to match the behavior of EAP6.
>>>>>>>> It can be
>>>>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>>>>> servlet
>>>>>>>> >>>> container. These JAPIC changes have been driven by this
>>>>>>>> change, in order to
>>>>>>>> >>>> get the TCK to pass without proactive auth. I will look into
>>>>>>>> it today.
>>>>>>>> >>>>
>>>>>>>> >>>> If you can contribute your tests it would be greatly
>>>>>>>> appreciated, we do
>>>>>>>> >>>> not have much coverage (and apparently neither does the TCK,
>>>>>>>> as it does not
>>>>>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>>>>>> author you
>>>>>>>> >>>> retain copyright and can re-license them under whatever
>>>>>>>> license you like.
>>>>>>>> >>>>
>>>>>>>> >>>> Stuart
>>>>>>>> >>>>
>>>>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <
>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Hi,
>>>>>>>> >>>>>
>>>>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>>>>> >>>>>
>>>>>>>> >>>>> pre-emptive authentication on a public page doesn't work
>>>>>>>> anymore
>>>>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>>>> >>>>>
>>>>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>>>>> >>>>>
>>>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>>>> >>>>>
>>>>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>>>>> >>>>>
>>>>>>>> >>>>> Failed tests:
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>> >>>>>
>>>>>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>>>>>> >>>>> automatic calling of a SAM at the beginning of a request.
>>>>>>>> After manual
>>>>>>>> >>>>> inspection it's clear that the SAM is called, but its outcome
>>>>>>>> is not
>>>>>>>> >>>>> being applied.
>>>>>>>> >>>>>
>>>>>>>> >>>>> Kind regards,
>>>>>>>> >>>>> Arjan
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>> >>>>> wrote:
>>>>>>>> >>>>> > Hi,
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > There are two main issues, and they're both in this
>>>>>>>> fragment in
>>>>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > if(isValid == null) {
>>>>>>>> >>>>> >     isValid =
>>>>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>>>>> JBossCallbackHandler());
>>>>>>>> >>>>> > }
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > The first problem is the "isValid == null" check. After the
>>>>>>>> first call
>>>>>>>> >>>>> > to request#authenticate in a given request this will always
>>>>>>>> be
>>>>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>>>>> authentication
>>>>>>>> >>>>> > will effectively be ignored the first time.
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > The second problem is that this passes in the
>>>>>>>> JBossCallbackHandler,
>>>>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and
>>>>>>>> this will
>>>>>>>> >>>>> > result in an exception like the following:
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>>>>>> PBOX00014:
>>>>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does
>>>>>>>> not handle
>>>>>>>> >>>>> > a callback of type
>>>>>>>> >>>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>>>>>>> >>>>> >     at
>>>>>>>> >>>>> >
>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>>>>> >>>>> >     at
>>>>>>>> >>>>> >
>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of
>>>>>>>> removing the
>>>>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>>>>> handler.
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > Kind regards,
>>>>>>>> >>>>> > Arjan Tijms
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> >
>>>>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>> >>>>> > wrote:
>>>>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>>>>>> previous
>>>>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler, then
>>>>>>>> everything
>>>>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>>>>> perhaps, but in
>>>>>>>> >>>>> >> some quick testing it does do the trick.
>>>>>>>> >>>>> >>
>>>>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>> >>>>> >> wrote:
>>>>>>>> >>>>> >>> Hi,
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit
>>>>>>>> specifically
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>>
>>>>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>>>>> )
>>>>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do
>>>>>>>> anything.
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> There it now obtains the attachment that was set by the
>>>>>>>> new
>>>>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the
>>>>>>>> beginning of the
>>>>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>>>>> directly, without
>>>>>>>> >>>>> >>> calling the SAM again.
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> See the code below:
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>>>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>>>>> >>>>> >>> attachment.getRequestContext();
>>>>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>>>>> >>>>> >>> attachment.getSam();
>>>>>>>> >>>>> >>>         final JASPICallbackHandler cbh =
>>>>>>>> attachment.getCbh();
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>>>>> attachment.getMessageInfo();
>>>>>>>> >>>>> >>>         if (isValid) {
>>>>>>>> >>>>> >>>             // The CBH filled in the JBOSS
>>>>>>>> SecurityContext, we need
>>>>>>>> >>>>> >>> to
>>>>>>>> >>>>> >>> create an Undertow account based on that
>>>>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>>>>> >>>>> >>>             authenticatedAccount =
>>>>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>>>>> >>>>> >>>         }
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> This is not correct I think. The code should call the SAM
>>>>>>>> once again
>>>>>>>> >>>>> >>> and use the outcome from that call.
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM
>>>>>>>> simply
>>>>>>>> >>>>> >>> forgotten at this point?
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>> Kind regards,
>>>>>>>> >>>>> >>> Arjan Tijms
>>>>>>>> >>>>> _______________________________________________
>>>>>>>> >>>>> wildfly-dev mailing list
>>>>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>> >>>>
>>>>>>>> >>>> _______________________________________________
>>>>>>>> >>>> wildfly-dev mailing list
>>>>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/947f53cd/attachment-0001.html 

From arjan.tijms at gmail.com  Wed Oct 21 07:51:33 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 21 Oct 2015 13:51:33 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c56Tc=dqOF6SO30-DZc6NQ6S2PO4F27_v2=yiFrXx8LCg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
	<CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
	<CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>
	<CAE=-AhB7W3=Y_=qWCoT4-JQmiA8FRCNB_MuTGyEWzXaBpdg8sg@mail.gmail.com>
	<CAAoo=c56Tc=dqOF6SO30-DZc6NQ6S2PO4F27_v2=yiFrXx8LCg@mail.gmail.com>
Message-ID: <CAE=-AhC_xj45rMui+62GH=4Fvhcb=ggfBGSwS==Am3qPd8DXrw@mail.gmail.com>

Unfortunately I would not know how it should work with an async servlet.
This is certainly a good thing to have specified and/or clarified.

I have a test for async in the suite, but it only tests if the presence of
a SAM (that does nothing for that test) doesn't disturb an async dispatch
from happening.

What now seems to happen in most servers is the same thing as what happens
with a Servlet Filter. The SAM's secureResponse method is invoked after the
last Filter has returned, but at that point the request is not necessarily
done and another thread that has the AsyncContext can still write to the
response.

E.g.

1. Request starts
2. SAM validateRequest invoked
2. Filter doFilter() invoked, before/in chain.doFilter()
3. Servlet invoked, starts async, returns
4. Filter after chain.doFilter(), returns
5. SAM secureResponse invoked
6. Other thread writes to response, calls AsyncContext#complete()
7. Request ends

Just like an existing non-async aware GZIP filter would not just work with
an async servlet, a SAM that collects the response via a response wrapper
would not work either.

Kind regards,
Arjan Tijms









On Wed, Oct 21, 2015 at 11:46 AM, Stuart Douglas <stuart.w.douglas at gmail.com
> wrote:

> One thing I am still not clear on is how this should work with async
> servlet, do you have any ideas?
>
> Normally when a request has returned to the container it means it is done,
> however with async requests this is not the case.
>
> Stuart
>
> On Wed, 21 Oct 2015 at 19:51 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> On Wed, Oct 21, 2015 at 10:04 AM, Stuart Douglas <
>> stuart.w.douglas at gmail.com> wrote:
>>
>>> Ah, I just re-read the spec and we are invoking this in the wrong place,
>>> it should be invoked on call stack return like you say, and not on response
>>> commit. The spec explicitly states that this may be called after the
>>> response has already been commited, but recommends a SAM buffer the full
>>> response using a HttpServletResponseWrapper if this is a problem (section
>>> B.9 ).
>>>
>>
>> Okay, great to hear it's more clear now ;)
>>
>>
>>
>>
>>>
>>> Stuart
>>>
>>>
>>> On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <
>>>> stuart.w.douglas at gmail.com> wrote:
>>>>
>>>>> I had a quick look into this, and I think your test is invalid.
>>>>>
>>>>> Basically secureResponse() is called when the message is about to be
>>>>> sent, in the case of your example this happens when the call stack returns
>>>>> and the writer is closed. The means that secureResponse can't use the
>>>>> writer, as it has already been closed.
>>>>>
>>>>
>>>> To be 100% sure, I'll verify this with the sped lead, Ron Monzillo.
>>>> Indeed, I noticed earlier that Undertow was unable to write to the response
>>>> at that point. You're right that the test isn't fully clear on this, and I
>>>> already wanted to split it up in a "secureResponse called" (tested via some
>>>> other method) and "able to write to the response from secureResponse".
>>>>
>>>> My feeling says Undertow should not have closed the writer at this
>>>> point and writing to the response should be possible. It's what the RI
>>>> allows and what each and every other server including JBoss EAP 6 allows.
>>>>
>>>>
>>>>
>>>>> Even if the writer was not closed and the message was being commited
>>>>> due to the buffer being full this would still be wrong, as the writer would
>>>>> basically be writing to some random point in the middle of the stream.
>>>>>
>>>>
>>>> I'm not sure this is correct. secureResponse is not called whenever the
>>>> buffer is full, but only after the (Servlet) resource has been invoked
>>>> (meaning, after the target Servlet has executed and control returns from
>>>> the last Filter).
>>>>
>>>> One usecase for this is capturing the response fully via a wrapped
>>>> response, and then in secureResponse, well, securing this in some way
>>>> (perhaps encrypting it). As such it's quite like how a GZIP filter
>>>> functions. Clearly the SAM has to be able to write to the response at that
>>>> point.
>>>>
>>>> As said, to be 100% sure I'll verify this with Ron.
>>>>
>>>> Kind regards,
>>>> Arjan Tijms
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>
>>>>>>> Is this with proactive auth disabled?
>>>>>>>
>>>>>>
>>>>>> It's with as much of the defaults as is possible.
>>>>>>
>>>>>> Just unzipped a clean download of CR3, added the dummy activation
>>>>>> code to standalone.xml, which is:
>>>>>>
>>>>>> <security-domain name="jaspitest" cache-type="default">
>>>>>>     <authentication-jaspi>
>>>>>>         <login-module-stack name="dummy">
>>>>>>             <login-module code="Dummy" flag="optional"/>
>>>>>>         </login-module-stack>
>>>>>>         <auth-module code="Dummy"/>
>>>>>>     </authentication-jaspi>
>>>>>> </security-domain>
>>>>>>
>>>>>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>>>>>> removed all modules in pom.xml except the JASPIC and support ones:
>>>>>>
>>>>>>     <modules>
>>>>>>       <module>test-utils</module>
>>>>>>       <module>jaspic</module>
>>>>>>       <module>util</module>
>>>>>>     </modules>
>>>>>>
>>>>>> Then in the root of the Java EE 7 project executed the following
>>>>>> command:
>>>>>>
>>>>>> mvn --fail-at-end test
>>>>>>
>>>>>> So this is with all defaults, which I guess is true (enabled) then
>>>>>> for what you call "proactive" according to this commit:
>>>>>>
>>>>>>
>>>>>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>>>>>
>>>>>> Kind regards,
>>>>>> Arjan Tijms
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>>>>>> well, since the behaviour is back to that of WildFly 9.
>>>>>>>>
>>>>>>>> Meaning, most tests from the EE 7 samples now pass again, but
>>>>>>>> calling of secureResponse (which 5298 was supposed to fix I think) now
>>>>>>>> fails again:
>>>>>>>>
>>>>>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>>>>>> SAM method secureResponse not called, but should have been.
>>>>>>>>
>>>>>>>>
>>>>>>>> The JSF includes still fail too, but those were failing in WildFly
>>>>>>>> 9 as well:
>>>>>>>>
>>>>>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>>
>>>>>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Arjan Tijms
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <arjan.tijms at gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>>>>>
>>>>>>>>> If there's anything I can do to help just let me know.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Arjan Tijms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <arjan.tijms at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Hi,
>>>>>>>>> >
>>>>>>>>> > Just wondering, any updates here? Did you tried to run the JASPIC
>>>>>>>>> > tests against the latest nightly?
>>>>>>>>> >
>>>>>>>>> > Kind regards,
>>>>>>>>> > Arjan Tijms
>>>>>>>>> >
>>>>>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>> >> Hi,
>>>>>>>>> >>
>>>>>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>>>>>> >>> Can you verify that this PR:
>>>>>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>>>>>> >>> fixes your issues?
>>>>>>>>> >>
>>>>>>>>> >> I did a quick test run, but now really everything breaks.
>>>>>>>>> >>
>>>>>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>>>>>> >>
>>>>>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>>>>>> >>
>>>>>>>>> >> But the constructor arguments are reversed.
>>>>>>>>> >>
>>>>>>>>> >> The arguments are defined as:
>>>>>>>>> >>
>>>>>>>>> >>  public JASPIAuthenticationMechanism(final String
>>>>>>>>> securityDomain,
>>>>>>>>> >> final String configuredAuthMethod) {
>>>>>>>>> >>
>>>>>>>>> >> When I reverse the arguments to their correct order, the same
>>>>>>>>> tests as
>>>>>>>>> >> before fail unfortunately.
>>>>>>>>> >>
>>>>>>>>> >> This individual case can be rather easily debugged manually by
>>>>>>>>> cloning
>>>>>>>>> >> the project using Eclipse/JBoss tools from
>>>>>>>>> >> https://github.com/javaee-samples/javaee7-samples Then
>>>>>>>>> importing just
>>>>>>>>> >> the jaspic and test-utils directories as Maven projects, and
>>>>>>>>> then
>>>>>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove on
>>>>>>>>> the
>>>>>>>>> >> server.
>>>>>>>>> >>
>>>>>>>>> >> If you then request:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>>>>>> >>
>>>>>>>>> >> You should see the same output as:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>>>>>> >>
>>>>>>>>> >> Hope this helps
>>>>>>>>> >>
>>>>>>>>> >> Kind regards,
>>>>>>>>> >> Arjan Tijms
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>>
>>>>>>>>> >>> Basically it reverts the recent changes, and instead installs
>>>>>>>>> a handler
>>>>>>>>> >>> after authenticate to handle requests that do not require
>>>>>>>>> authentication.
>>>>>>>>> >>>
>>>>>>>>> >>> Stuart
>>>>>>>>> >>>
>>>>>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>>>>>> jason.greene at redhat.com>
>>>>>>>>> >>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>>>>>> stuart.w.douglas at gmail.com>
>>>>>>>>> >>>> wrote:
>>>>>>>>> >>>>
>>>>>>>>> >>>> This was deliberately disabled to match the behavior of EAP6.
>>>>>>>>> It can be
>>>>>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>>>>>> servlet
>>>>>>>>> >>>> container. These JAPIC changes have been driven by this
>>>>>>>>> change, in order to
>>>>>>>>> >>>> get the TCK to pass without proactive auth. I will look into
>>>>>>>>> it today.
>>>>>>>>> >>>>
>>>>>>>>> >>>> If you can contribute your tests it would be greatly
>>>>>>>>> appreciated, we do
>>>>>>>>> >>>> not have much coverage (and apparently neither does the TCK,
>>>>>>>>> as it does not
>>>>>>>>> >>>> pick up these issues). As I understand it if you are the sole
>>>>>>>>> author you
>>>>>>>>> >>>> retain copyright and can re-license them under whatever
>>>>>>>>> license you like.
>>>>>>>>> >>>>
>>>>>>>>> >>>> Stuart
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Hi,
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> pre-emptive authentication on a public page doesn't work
>>>>>>>>> anymore
>>>>>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>>>>>> >>>>>
>>>>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Failed tests:
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> These tests don't rely on request#authenticate, but depend on
>>>>>>>>> >>>>> automatic calling of a SAM at the beginning of a request.
>>>>>>>>> After manual
>>>>>>>>> >>>>> inspection it's clear that the SAM is called, but its
>>>>>>>>> outcome is not
>>>>>>>>> >>>>> being applied.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Kind regards,
>>>>>>>>> >>>>> Arjan
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>> >>>>> wrote:
>>>>>>>>> >>>>> > Hi,
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > There are two main issues, and they're both in this
>>>>>>>>> fragment in
>>>>>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > if(isValid == null) {
>>>>>>>>> >>>>> >     isValid =
>>>>>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>>>>>> JBossCallbackHandler());
>>>>>>>>> >>>>> > }
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > The first problem is the "isValid == null" check. After
>>>>>>>>> the first call
>>>>>>>>> >>>>> > to request#authenticate in a given request this will
>>>>>>>>> always be
>>>>>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>>>>>> authentication
>>>>>>>>> >>>>> > will effectively be ignored the first time.
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > The second problem is that this passes in the
>>>>>>>>> JBossCallbackHandler,
>>>>>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and
>>>>>>>>> this will
>>>>>>>>> >>>>> > result in an exception like the following:
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > javax.security.auth.callback.UnsupportedCallbackException:
>>>>>>>>> PBOX00014:
>>>>>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler does
>>>>>>>>> not handle
>>>>>>>>> >>>>> > a callback of type
>>>>>>>>> >>>>> >
>>>>>>>>> javax.security.auth.message.callback.CallerPrincipalCallback
>>>>>>>>> >>>>> >     at
>>>>>>>>> >>>>> >
>>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>>>>>> >>>>> >     at
>>>>>>>>> >>>>> >
>>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of
>>>>>>>>> removing the
>>>>>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>>>>>> handler.
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > Kind regards,
>>>>>>>>> >>>>> > Arjan Tijms
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> >
>>>>>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>> >>>>> > wrote:
>>>>>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the
>>>>>>>>> previous
>>>>>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler,
>>>>>>>>> then everything
>>>>>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>>>>>> perhaps, but in
>>>>>>>>> >>>>> >> some quick testing it does do the trick.
>>>>>>>>> >>>>> >>
>>>>>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>> >>>>> >> wrote:
>>>>>>>>> >>>>> >>> Hi,
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit
>>>>>>>>> specifically
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>>
>>>>>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>>>>>> )
>>>>>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do
>>>>>>>>> anything.
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> There it now obtains the attachment that was set by the
>>>>>>>>> new
>>>>>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the
>>>>>>>>> beginning of the
>>>>>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>>>>>> directly, without
>>>>>>>>> >>>>> >>> calling the SAM again.
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> See the code below:
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>>   public AuthenticationMechanismOutcome
>>>>>>>>> authenticate(final
>>>>>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>>>>>> >>>>> >>> attachment.getRequestContext();
>>>>>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>>>>>> >>>>> >>> attachment.getSam();
>>>>>>>>> >>>>> >>>         final JASPICallbackHandler cbh =
>>>>>>>>> attachment.getCbh();
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>>>>>> attachment.getMessageInfo();
>>>>>>>>> >>>>> >>>         if (isValid) {
>>>>>>>>> >>>>> >>>             // The CBH filled in the JBOSS
>>>>>>>>> SecurityContext, we need
>>>>>>>>> >>>>> >>> to
>>>>>>>>> >>>>> >>> create an Undertow account based on that
>>>>>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>>>>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>>>>>> >>>>> >>>             authenticatedAccount =
>>>>>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>>>>>> >>>>> >>>         }
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> This is not correct I think. The code should call the
>>>>>>>>> SAM once again
>>>>>>>>> >>>>> >>> and use the outcome from that call.
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM
>>>>>>>>> simply
>>>>>>>>> >>>>> >>> forgotten at this point?
>>>>>>>>> >>>>> >>>
>>>>>>>>> >>>>> >>> Kind regards,
>>>>>>>>> >>>>> >>> Arjan Tijms
>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>> >>>>> wildfly-dev mailing list
>>>>>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>> >>>>
>>>>>>>>> >>>> _______________________________________________
>>>>>>>>> >>>> wildfly-dev mailing list
>>>>>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/5d6eb902/attachment-0001.html 

From jnethert at redhat.com  Wed Oct 21 08:52:32 2015
From: jnethert at redhat.com (James Netherton)
Date: Wed, 21 Oct 2015 08:52:32 -0400 (EDT)
Subject: [wildfly-dev] Feature pack maven plugins question
In-Reply-To: <1013147646.61867173.1445430248945.JavaMail.zimbra@redhat.com>
Message-ID: <1487621985.61883632.1445431952943.JavaMail.zimbra@redhat.com>

Hello everyone,

Consider the following.

Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:

<dependencies>
??<artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
</dependencies>

Feature pack 'B' has a dependency on the WildFly 10 feature pack and also on feature pack 'A'. E.g:

<dependencies>
??<artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
??<artifact name="org.foo:feature-pack-A" />
</dependencies>

Leaving the sanity and validity of doing this aside, should the feature-pack-build or server-provisioning-plugin be detecting this as an error condition, given that you'll have overlapping and possibly problematic non-overlapping file paths coming from the conflicting WildFly versions?

At the moment the plugins allow this scenario. 

Cheers,

James


From tomaz.cerar at gmail.com  Wed Oct 21 09:00:58 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 21 Oct 2015 15:00:58 +0200
Subject: [wildfly-dev] Feature pack maven plugins question
In-Reply-To: <1487621985.61883632.1445431952943.JavaMail.zimbra@redhat.com>
References: <1013147646.61867173.1445430248945.JavaMail.zimbra@redhat.com>
	<1487621985.61883632.1445431952943.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP5suoxY+4MeCsGMh9Ro0DDa2MaswKLQHw97bi20gPqL8A@mail.gmail.com>

If you would add maven-enforcer-plugin it would fail if you try to add
something like this.

We rely on it for this kind checking in WildFly build.

--
tomaz

On Wed, Oct 21, 2015 at 2:52 PM, James Netherton <jnethert at redhat.com>
wrote:

> Hello everyone,
>
> Consider the following.
>
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
>
> <dependencies>
>   <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
>
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also
> on feature pack 'A'. E.g:
>
> <dependencies>
>   <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
>   <artifact name="org.foo:feature-pack-A" />
> </dependencies>
>
> Leaving the sanity and validity of doing this aside, should the
> feature-pack-build or server-provisioning-plugin be detecting this as an
> error condition, given that you'll have overlapping and possibly
> problematic non-overlapping file paths coming from the conflicting WildFly
> versions?
>
> At the moment the plugins allow this scenario.
>
> Cheers,
>
> James
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/a4efc28d/attachment.html 

From jnethert at redhat.com  Wed Oct 21 10:31:57 2015
From: jnethert at redhat.com (James Netherton)
Date: Wed, 21 Oct 2015 10:31:57 -0400 (EDT)
Subject: [wildfly-dev] Feature pack maven plugins question
In-Reply-To: <CAMquZP5suoxY+4MeCsGMh9Ro0DDa2MaswKLQHw97bi20gPqL8A@mail.gmail.com>
References: <1013147646.61867173.1445430248945.JavaMail.zimbra@redhat.com>
	<1487621985.61883632.1445431952943.JavaMail.zimbra@redhat.com>
	<CAMquZP5suoxY+4MeCsGMh9Ro0DDa2MaswKLQHw97bi20gPqL8A@mail.gmail.com>
Message-ID: <586295954.61983779.1445437917398.JavaMail.zimbra@redhat.com>

I think the feature pack plugins will avoid any enforced rules as they use the aether api directly to resolve their dependencies. So it is possible for conflicting artifacts to be resolved in a feature pack dependency chain.

----- Original Message -----
From: "Toma? Cerar" <tomaz.cerar at gmail.com>
To: "James Netherton" <jnethert at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Wednesday, 21 October, 2015 2:00:58 PM
Subject: Re: [wildfly-dev] Feature pack maven plugins question

If you would add maven-enforcer-plugin it would fail if you try to add
something like this.

We rely on it for this kind checking in WildFly build.

--
tomaz

On Wed, Oct 21, 2015 at 2:52 PM, James Netherton <jnethert at redhat.com>
wrote:

> Hello everyone,
>
> Consider the following.
>
> Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
>
> <dependencies>
> ? <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> </dependencies>
>
> Feature pack 'B' has a dependency on the WildFly 10 feature pack and also
> on feature pack 'A'. E.g:
>
> <dependencies>
> ? <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> ? <artifact name="org.foo:feature-pack-A" />
> </dependencies>
>
> Leaving the sanity and validity of doing this aside, should the
> feature-pack-build or server-provisioning-plugin be detecting this as an
> error condition, given that you'll have overlapping and possibly
> problematic non-overlapping file paths coming from the conflicting WildFly
> versions?
>
> At the moment the plugins allow this scenario.
>
> Cheers,
>
> James
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From stuart.w.douglas at gmail.com  Wed Oct 21 16:00:49 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 21 Oct 2015 20:00:49 +0000
Subject: [wildfly-dev] Feature pack maven plugins question
In-Reply-To: <586295954.61983779.1445437917398.JavaMail.zimbra@redhat.com>
References: <1013147646.61867173.1445430248945.JavaMail.zimbra@redhat.com>
	<1487621985.61883632.1445431952943.JavaMail.zimbra@redhat.com>
	<CAMquZP5suoxY+4MeCsGMh9Ro0DDa2MaswKLQHw97bi20gPqL8A@mail.gmail.com>
	<586295954.61983779.1445437917398.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c5yycjJZLiAfrPU9OhKMqmTp4T93cp9FR58B472Eq7cRg@mail.gmail.com>

I think this should be an error that is picked up by the plugin. Can you
file a JIRA at https://issues.jboss.org/browse/WFBUILD ?

Thanks,

Stuart

On Thu, 22 Oct 2015 at 01:32 James Netherton <jnethert at redhat.com> wrote:

> I think the feature pack plugins will avoid any enforced rules as they use
> the aether api directly to resolve their dependencies. So it is possible
> for conflicting artifacts to be resolved in a feature pack dependency chain.
>
> ----- Original Message -----
> From: "Toma? Cerar" <tomaz.cerar at gmail.com>
> To: "James Netherton" <jnethert at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Wednesday, 21 October, 2015 2:00:58 PM
> Subject: Re: [wildfly-dev] Feature pack maven plugins question
>
> If you would add maven-enforcer-plugin it would fail if you try to add
> something like this.
>
> We rely on it for this kind checking in WildFly build.
>
> --
> tomaz
>
> On Wed, Oct 21, 2015 at 2:52 PM, James Netherton <jnethert at redhat.com>
> wrote:
>
> > Hello everyone,
> >
> > Consider the following.
> >
> > Feature pack 'A' has a dependency on the WildFly 9 feature pack. E.g:
> >
> > <dependencies>
> >   <artifact name="org.wildfly:wildfly-feature-pack:9.0.1.Final" />
> > </dependencies>
> >
> > Feature pack 'B' has a dependency on the WildFly 10 feature pack and also
> > on feature pack 'A'. E.g:
> >
> > <dependencies>
> >   <artifact name="org.wildfly:wildfly-feature-pack:10.0.0.CR3" />
> >   <artifact name="org.foo:feature-pack-A" />
> > </dependencies>
> >
> > Leaving the sanity and validity of doing this aside, should the
> > feature-pack-build or server-provisioning-plugin be detecting this as an
> > error condition, given that you'll have overlapping and possibly
> > problematic non-overlapping file paths coming from the conflicting
> WildFly
> > versions?
> >
> > At the moment the plugins allow this scenario.
> >
> > Cheers,
> >
> > James
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/b8ca5d01/attachment.html 

From stuart.w.douglas at gmail.com  Wed Oct 21 18:54:18 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 21 Oct 2015 22:54:18 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhC_xj45rMui+62GH=4Fvhcb=ggfBGSwS==Am3qPd8DXrw@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
	<CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>
	<CAE=-AhAU+hj_VsgrhsH9Xe8tVKF4MOO067uPe-=ihNRCSf_-Rg@mail.gmail.com>
	<CAE=-AhBXxNBsjOhcYGRDOS2kJ7vLkj=DeZhhvbGyeGS7od=tpg@mail.gmail.com>
	<CAE=-AhBJfBrxDOXRJ_nsBVEdvg7H8z7-MrmJLWV_CROGWPVrHg@mail.gmail.com>
	<CAAoo=c72PtCFoo6B1pHKaagZc=oGvYL7yhRq=+6hOQzgM_LP+Q@mail.gmail.com>
	<CAE=-AhC4J1Sxr2=Jjn_Tpo=MD-=BNgt_yEFJykYRN4_2fN9WFg@mail.gmail.com>
	<CAAoo=c4tX7p16-BS8w14XVhVsNnOzh9JPHBhZSfger7nYqgo9A@mail.gmail.com>
	<CAE=-AhAdEct3F5Rj3ATZbkTAEF04QmwJnExFr5U5O_vpeMFenw@mail.gmail.com>
	<CAAoo=c4Uh2-DMeHrAs4-HuFOkRYTTwFu9A7+Ub_dCP27mBJ=yg@mail.gmail.com>
	<CAE=-AhB7W3=Y_=qWCoT4-JQmiA8FRCNB_MuTGyEWzXaBpdg8sg@mail.gmail.com>
	<CAAoo=c56Tc=dqOF6SO30-DZc6NQ6S2PO4F27_v2=yiFrXx8LCg@mail.gmail.com>
	<CAE=-AhC_xj45rMui+62GH=4Fvhcb=ggfBGSwS==Am3qPd8DXrw@mail.gmail.com>
Message-ID: <CAAoo=c4xqvL0CVsjbdwYVvTFErCPNmgXCSZVaPXrgaNrxRbRBg@mail.gmail.com>

https://github.com/wildfly/wildfly/pull/8316

Should fix the issue.

Stuart


On Wed, 21 Oct 2015 at 22:51 arjan tijms <arjan.tijms at gmail.com> wrote:

> Unfortunately I would not know how it should work with an async servlet.
> This is certainly a good thing to have specified and/or clarified.
>
> I have a test for async in the suite, but it only tests if the presence of
> a SAM (that does nothing for that test) doesn't disturb an async dispatch
> from happening.
>
> What now seems to happen in most servers is the same thing as what happens
> with a Servlet Filter. The SAM's secureResponse method is invoked after the
> last Filter has returned, but at that point the request is not necessarily
> done and another thread that has the AsyncContext can still write to the
> response.
>
> E.g.
>
> 1. Request starts
> 2. SAM validateRequest invoked
> 2. Filter doFilter() invoked, before/in chain.doFilter()
> 3. Servlet invoked, starts async, returns
> 4. Filter after chain.doFilter(), returns
> 5. SAM secureResponse invoked
> 6. Other thread writes to response, calls AsyncContext#complete()
> 7. Request ends
>
> Just like an existing non-async aware GZIP filter would not just work with
> an async servlet, a SAM that collects the response via a response wrapper
> would not work either.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
> On Wed, Oct 21, 2015 at 11:46 AM, Stuart Douglas <
> stuart.w.douglas at gmail.com> wrote:
>
>> One thing I am still not clear on is how this should work with async
>> servlet, do you have any ideas?
>>
>> Normally when a request has returned to the container it means it is
>> done, however with async requests this is not the case.
>>
>> Stuart
>>
>> On Wed, 21 Oct 2015 at 19:51 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>>> On Wed, Oct 21, 2015 at 10:04 AM, Stuart Douglas <
>>> stuart.w.douglas at gmail.com> wrote:
>>>
>>>> Ah, I just re-read the spec and we are invoking this in the wrong
>>>> place, it should be invoked on call stack return like you say, and not on
>>>> response commit. The spec explicitly states that this may be called after
>>>> the response has already been commited, but recommends a SAM buffer the
>>>> full response using a HttpServletResponseWrapper if this is a problem
>>>> (section B.9 ).
>>>>
>>>
>>> Okay, great to hear it's more clear now ;)
>>>
>>>
>>>
>>>
>>>>
>>>> Stuart
>>>>
>>>>
>>>> On Wed, 21 Oct 2015 at 18:24 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Oct 21, 2015 at 2:19 AM, Stuart Douglas <
>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>
>>>>>> I had a quick look into this, and I think your test is invalid.
>>>>>>
>>>>>> Basically secureResponse() is called when the message is about to be
>>>>>> sent, in the case of your example this happens when the call stack returns
>>>>>> and the writer is closed. The means that secureResponse can't use the
>>>>>> writer, as it has already been closed.
>>>>>>
>>>>>
>>>>> To be 100% sure, I'll verify this with the sped lead, Ron Monzillo.
>>>>> Indeed, I noticed earlier that Undertow was unable to write to the response
>>>>> at that point. You're right that the test isn't fully clear on this, and I
>>>>> already wanted to split it up in a "secureResponse called" (tested via some
>>>>> other method) and "able to write to the response from secureResponse".
>>>>>
>>>>> My feeling says Undertow should not have closed the writer at this
>>>>> point and writing to the response should be possible. It's what the RI
>>>>> allows and what each and every other server including JBoss EAP 6 allows.
>>>>>
>>>>>
>>>>>
>>>>>> Even if the writer was not closed and the message was being commited
>>>>>> due to the buffer being full this would still be wrong, as the writer would
>>>>>> basically be writing to some random point in the middle of the stream.
>>>>>>
>>>>>
>>>>> I'm not sure this is correct. secureResponse is not called whenever
>>>>> the buffer is full, but only after the (Servlet) resource has been invoked
>>>>> (meaning, after the target Servlet has executed and control returns from
>>>>> the last Filter).
>>>>>
>>>>> One usecase for this is capturing the response fully via a wrapped
>>>>> response, and then in secureResponse, well, securing this in some way
>>>>> (perhaps encrypting it). As such it's quite like how a GZIP filter
>>>>> functions. Clearly the SAM has to be able to write to the response at that
>>>>> point.
>>>>>
>>>>> As said, to be 100% sure I'll verify this with Ron.
>>>>>
>>>>> Kind regards,
>>>>> Arjan Tijms
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Stuart
>>>>>>
>>>>>> On Wed, 21 Oct 2015 at 10:04 arjan tijms <arjan.tijms at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Oct 21, 2015 at 12:26 AM, Stuart Douglas <
>>>>>>> stuart.w.douglas at gmail.com> wrote:
>>>>>>>
>>>>>>>> Is this with proactive auth disabled?
>>>>>>>>
>>>>>>>
>>>>>>> It's with as much of the defaults as is possible.
>>>>>>>
>>>>>>> Just unzipped a clean download of CR3, added the dummy activation
>>>>>>> code to standalone.xml, which is:
>>>>>>>
>>>>>>> <security-domain name="jaspitest" cache-type="default">
>>>>>>>     <authentication-jaspi>
>>>>>>>         <login-module-stack name="dummy">
>>>>>>>             <login-module code="Dummy" flag="optional"/>
>>>>>>>         </login-module-stack>
>>>>>>>         <auth-module code="Dummy"/>
>>>>>>>     </authentication-jaspi>
>>>>>>> </security-domain>
>>>>>>>
>>>>>>> Started WildFly via JBoss tools, then in Java EE 7 samples project
>>>>>>> removed all modules in pom.xml except the JASPIC and support ones:
>>>>>>>
>>>>>>>     <modules>
>>>>>>>       <module>test-utils</module>
>>>>>>>       <module>jaspic</module>
>>>>>>>       <module>util</module>
>>>>>>>     </modules>
>>>>>>>
>>>>>>> Then in the root of the Java EE 7 project executed the following
>>>>>>> command:
>>>>>>>
>>>>>>> mvn --fail-at-end test
>>>>>>>
>>>>>>> So this is with all defaults, which I guess is true (enabled) then
>>>>>>> for what you call "proactive" according to this commit:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/wildfly/wildfly/commit/8a41c10eb56a827332355b921834c85e4a516389
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Arjan Tijms
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>>
>>>>>>>> On Wed, 21 Oct 2015 at 09:02 arjan tijms <arjan.tijms at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I just tested WildFly 10.0.0 rc3 and the revert seems to have gone
>>>>>>>>> well, since the behaviour is back to that of WildFly 9.
>>>>>>>>>
>>>>>>>>> Meaning, most tests from the EE 7 samples now pass again, but
>>>>>>>>> calling of secureResponse (which 5298 was supposed to fix I think) now
>>>>>>>>> fails again:
>>>>>>>>>
>>>>>>>>> testBasicSAMMethodsCalled(org.javaee7.jaspic.lifecycle.AuthModuleMethodInvocationTest):
>>>>>>>>> SAM method secureResponse not called, but should have been.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The JSF includes still fail too, but those were failing in WildFly
>>>>>>>>> 9 as well:
>>>>>>>>>
>>>>>>>>> testJSFwithCDIIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFCDIIncludeTest):
>>>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>>>
>>>>>>>>> testJSFIncludeViaPublicResource(org.javaee7.jaspictest.dispatching.JSFIncludeTest):
>>>>>>>>> Response did not contain output from JSF view that SAM included.
>>>>>>>>>
>>>>>>>>> Kind regards,
>>>>>>>>> Arjan Tijms
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Oct 13, 2015 at 1:16 PM, arjan tijms <
>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Sorry to ask again, but any news on this topic yet?
>>>>>>>>>>
>>>>>>>>>> If there's anything I can do to help just let me know.
>>>>>>>>>>
>>>>>>>>>> Kind regards,
>>>>>>>>>> Arjan Tijms
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Oct 5, 2015 at 3:46 PM, arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>>> > Hi,
>>>>>>>>>> >
>>>>>>>>>> > Just wondering, any updates here? Did you tried to run the
>>>>>>>>>> JASPIC
>>>>>>>>>> > tests against the latest nightly?
>>>>>>>>>> >
>>>>>>>>>> > Kind regards,
>>>>>>>>>> > Arjan Tijms
>>>>>>>>>> >
>>>>>>>>>> > On Mon, Sep 28, 2015 at 4:58 PM, arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>>> >> Hi,
>>>>>>>>>> >>
>>>>>>>>>> >> On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
>>>>>>>>>> >> <stuart.w.douglas at gmail.com> wrote:
>>>>>>>>>> >>> Can you verify that this PR:
>>>>>>>>>> https://github.com/wildfly/wildfly/pull/8204
>>>>>>>>>> >>> fixes your issues?
>>>>>>>>>> >>
>>>>>>>>>> >> I did a quick test run, but now really everything breaks.
>>>>>>>>>> >>
>>>>>>>>>> >> In UndertowDeploymentInfoService the following line occurs:
>>>>>>>>>> >>
>>>>>>>>>> >>  deploymentInfo.setJaspiAuthenticationMechanism(new
>>>>>>>>>> >> JASPIAuthenticationMechanism(authMethod, securityDomain));
>>>>>>>>>> >>
>>>>>>>>>> >> But the constructor arguments are reversed.
>>>>>>>>>> >>
>>>>>>>>>> >> The arguments are defined as:
>>>>>>>>>> >>
>>>>>>>>>> >>  public JASPIAuthenticationMechanism(final String
>>>>>>>>>> securityDomain,
>>>>>>>>>> >> final String configuredAuthMethod) {
>>>>>>>>>> >>
>>>>>>>>>> >> When I reverse the arguments to their correct order, the same
>>>>>>>>>> tests as
>>>>>>>>>> >> before fail unfortunately.
>>>>>>>>>> >>
>>>>>>>>>> >> This individual case can be rather easily debugged manually by
>>>>>>>>>> cloning
>>>>>>>>>> >> the project using Eclipse/JBoss tools from
>>>>>>>>>> >> https://github.com/javaee-samples/javaee7-samples Then
>>>>>>>>>> importing just
>>>>>>>>>> >> the jaspic and test-utils directories as Maven projects, and
>>>>>>>>>> then
>>>>>>>>>> >> deploying "jaspic-basic-authentication" using Add and Remove
>>>>>>>>>> on the
>>>>>>>>>> >> server.
>>>>>>>>>> >>
>>>>>>>>>> >> If you then request:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin
>>>>>>>>>> >>
>>>>>>>>>> >> You should see the same output as:
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin
>>>>>>>>>> >>
>>>>>>>>>> >> Hope this helps
>>>>>>>>>> >>
>>>>>>>>>> >> Kind regards,
>>>>>>>>>> >> Arjan Tijms
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>>
>>>>>>>>>> >>> Basically it reverts the recent changes, and instead installs
>>>>>>>>>> a handler
>>>>>>>>>> >>> after authenticate to handle requests that do not require
>>>>>>>>>> authentication.
>>>>>>>>>> >>>
>>>>>>>>>> >>> Stuart
>>>>>>>>>> >>>
>>>>>>>>>> >>> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <
>>>>>>>>>> jason.greene at redhat.com>
>>>>>>>>>> >>> wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> The MIT license also grants the ability to relicense.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <
>>>>>>>>>> stuart.w.douglas at gmail.com>
>>>>>>>>>> >>>> wrote:
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> This was deliberately disabled to match the behavior of
>>>>>>>>>> EAP6. It can be
>>>>>>>>>> >>>> controlled by the proactive-authentication attribute on the
>>>>>>>>>> servlet
>>>>>>>>>> >>>> container. These JAPIC changes have been driven by this
>>>>>>>>>> change, in order to
>>>>>>>>>> >>>> get the TCK to pass without proactive auth. I will look into
>>>>>>>>>> it today.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> If you can contribute your tests it would be greatly
>>>>>>>>>> appreciated, we do
>>>>>>>>>> >>>> not have much coverage (and apparently neither does the TCK,
>>>>>>>>>> as it does not
>>>>>>>>>> >>>> pick up these issues). As I understand it if you are the
>>>>>>>>>> sole author you
>>>>>>>>>> >>>> retain copyright and can re-license them under whatever
>>>>>>>>>> license you like.
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> Stuart
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com> wrote:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Hi,
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> I discovered some more issues originating from 5298:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> pre-emptive authentication on a public page doesn't work
>>>>>>>>>> anymore
>>>>>>>>>> >>>>> either. It still worked fine in WildFly 9.0.1.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> This can be easily seen when running the JASPIC tests from
>>>>>>>>>> >>>>>
>>>>>>>>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> For the basic authentication tests, the following now fail:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Failed tests:
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> These tests don't rely on request#authenticate, but depend
>>>>>>>>>> on
>>>>>>>>>> >>>>> automatic calling of a SAM at the beginning of a request.
>>>>>>>>>> After manual
>>>>>>>>>> >>>>> inspection it's clear that the SAM is called, but its
>>>>>>>>>> outcome is not
>>>>>>>>>> >>>>> being applied.
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> Kind regards,
>>>>>>>>>> >>>>> Arjan
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>>> >>>>> wrote:
>>>>>>>>>> >>>>> > Hi,
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > I checked again on the just released WildFly 10.0 CR2, but
>>>>>>>>>> >>>>> > unfortunately the code is still severely broken now.
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > There are two main issues, and they're both in this
>>>>>>>>>> fragment in
>>>>>>>>>> >>>>> > JASPIAuthenticationMechanism:
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > if(isValid == null) {
>>>>>>>>>> >>>>> >     isValid =
>>>>>>>>>> createJASPIAuthenticationManager().isValid(messageInfo,
>>>>>>>>>> >>>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>>>>>>>>> >>>>> > attachment.getApplicationIdentifier(), new
>>>>>>>>>> JBossCallbackHandler());
>>>>>>>>>> >>>>> > }
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > The first problem is the "isValid == null" check. After
>>>>>>>>>> the first call
>>>>>>>>>> >>>>> > to request#authenticate in a given request this will
>>>>>>>>>> always be
>>>>>>>>>> >>>>> > non-null. The result is that a request for programmatic
>>>>>>>>>> authentication
>>>>>>>>>> >>>>> > will effectively be ignored the first time.
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > The second problem is that this passes in the
>>>>>>>>>> JBossCallbackHandler,
>>>>>>>>>> >>>>> > but this doesn't know how to handle JASPIC callbacks and
>>>>>>>>>> this will
>>>>>>>>>> >>>>> > result in an exception like the following:
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>>>>>>>>>> >>>>> > org.jboss.security.auth.callback.JBossCallbackHandler
>>>>>>>>>> does not handle
>>>>>>>>>> >>>>> > a callback of type
>>>>>>>>>> >>>>> >
>>>>>>>>>> javax.security.auth.message.callback.CallerPrincipalCallback
>>>>>>>>>> >>>>> >     at
>>>>>>>>>> >>>>> >
>>>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>>>>>>>>> >>>>> >     at
>>>>>>>>>> >>>>> >
>>>>>>>>>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > The code should pass in a JASPICallbackHandler here.
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > Hope this can be fixed. Perhaps it's just a matter of
>>>>>>>>>> removing the
>>>>>>>>>> >>>>> > "isValid == null" check and passing in the right callback
>>>>>>>>>> handler.
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > Kind regards,
>>>>>>>>>> >>>>> > Arjan Tijms
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> >
>>>>>>>>>> >>>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>>> >>>>> > wrote:
>>>>>>>>>> >>>>> >> p.s. if I just revert JASPIAuthenticationMechanism to
>>>>>>>>>> the previous
>>>>>>>>>> >>>>> >> version, but leaving in the new JASPICInitialHandler,
>>>>>>>>>> then everything
>>>>>>>>>> >>>>> >> seems to work again. This is a bit of hacky workaround
>>>>>>>>>> perhaps, but in
>>>>>>>>>> >>>>> >> some quick testing it does do the trick.
>>>>>>>>>> >>>>> >>
>>>>>>>>>> >>>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <
>>>>>>>>>> arjan.tijms at gmail.com>
>>>>>>>>>> >>>>> >> wrote:
>>>>>>>>>> >>>>> >>> Hi,
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> It looks like that after WFLY-5298 (this commit
>>>>>>>>>> specifically
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>>>>>>>>>> )
>>>>>>>>>> >>>>> >>> HttpServletRequest#authenticate does not longer do
>>>>>>>>>> anything.
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> HttpServletRequest#authenticate calls though to
>>>>>>>>>> >>>>> >>> JASPIAuthenticationMechanism#authenticate.
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> There it now obtains the attachment that was set by the
>>>>>>>>>> new
>>>>>>>>>> >>>>> >>> JASPICInitialHandler, which calls the SAM at the
>>>>>>>>>> beginning of the
>>>>>>>>>> >>>>> >>> request. And then uses the stored "isValid" outcome
>>>>>>>>>> directly, without
>>>>>>>>>> >>>>> >>> calling the SAM again.
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> See the code below:
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>>   public AuthenticationMechanismOutcome
>>>>>>>>>> authenticate(final
>>>>>>>>>> >>>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>>>>>>>>> >>>>> >>>         JASPICAttachment attachment =
>>>>>>>>>> >>>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>>         AuthenticationMechanismOutcome outcome;
>>>>>>>>>> >>>>> >>>         Account authenticatedAccount = null;
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>>         boolean isValid = attachment.isValid();
>>>>>>>>>> >>>>> >>>         final ServletRequestContext requestContext =
>>>>>>>>>> >>>>> >>> attachment.getRequestContext();
>>>>>>>>>> >>>>> >>>         final JASPIServerAuthenticationManager sam =
>>>>>>>>>> >>>>> >>> attachment.getSam();
>>>>>>>>>> >>>>> >>>         final JASPICallbackHandler cbh =
>>>>>>>>>> attachment.getCbh();
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>>         GenericMessageInfo messageInfo =
>>>>>>>>>> attachment.getMessageInfo();
>>>>>>>>>> >>>>> >>>         if (isValid) {
>>>>>>>>>> >>>>> >>>             // The CBH filled in the JBOSS
>>>>>>>>>> SecurityContext, we need
>>>>>>>>>> >>>>> >>> to
>>>>>>>>>> >>>>> >>> create an Undertow account based on that
>>>>>>>>>> >>>>> >>>             org.jboss.security.SecurityContext jbossSct
>>>>>>>>>> =
>>>>>>>>>> >>>>> >>> SecurityActions.getSecurityContext();
>>>>>>>>>> >>>>> >>>             authenticatedAccount =
>>>>>>>>>> >>>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>>>>>>>> >>>>> >>>         }
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> This is not correct I think. The code should call the
>>>>>>>>>> SAM once again
>>>>>>>>>> >>>>> >>> and use the outcome from that call.
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> Am I missing something, or was the new call to the SAM
>>>>>>>>>> simply
>>>>>>>>>> >>>>> >>> forgotten at this point?
>>>>>>>>>> >>>>> >>>
>>>>>>>>>> >>>>> >>> Kind regards,
>>>>>>>>>> >>>>> >>> Arjan Tijms
>>>>>>>>>> >>>>> _______________________________________________
>>>>>>>>>> >>>>> wildfly-dev mailing list
>>>>>>>>>> >>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>> >>>>
>>>>>>>>>> >>>> _______________________________________________
>>>>>>>>>> >>>> wildfly-dev mailing list
>>>>>>>>>> >>>> wildfly-dev at lists.jboss.org
>>>>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151021/5665b43c/attachment-0001.html 

From jason.greene at redhat.com  Thu Oct 22 09:37:10 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 22 Oct 2015 09:37:10 -0400 (EDT)
Subject: [wildfly-dev] WF 10 Last Call
Message-ID: <E9D5B127-FA71-4EE2-B220-3CA38FC54CC4@redhat.com>

I plan to cut CR4 early tomorrow, which baring a major blocker, will be our last CR. After CR4, only PRs which are blockers, or are part of the Final version update will be merged. After Final is released, master will be slated for post release bug fixes, and non blocking bugs can once again be merged.

WF11 will open up most likely around a month after the release, at the latest, to give adequate time for engaging the community and resolving issues discovered. 

If you have any critical bug fixes, today would be the day to get them in.

Thanks,
-Jason




From arjan.tijms at gmail.com  Fri Oct 30 05:19:59 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 30 Oct 2015 10:19:59 +0100
Subject: [wildfly-dev] Adding additional security domain to standalone.xml?
Message-ID: <CAE=-AhA+S4ptXd2W2UcTr=JhVK8rjU2Rs3auYKgHHjYhTdp5YA@mail.gmail.com>

Hi,

Currently one has to "activate" JASPIC in WildFly by doing two things:

1. Adding a generic "dummy" security domain to standalone.xml
2. Referencing this domain from a jboss-web.xml within the application
archive

I wonder if it would make sense to put the generic jaspic security domain
by default in standalone.xml. It's always the same anyway. With the domain
present in a stock WildFly it's much easier for people to start with JASPIC
on WildFly.

It concerns this fragment:

 <security-domain name="jaspitest" cache-type="default">
    <authentication-jaspi>
        <login-module-stack name="dummy">
            <login-module code="Dummy" flag="optional"/>
        </login-module-stack>
        <auth-module code="Dummy"/>
    </authentication-jaspi>
 </security-domain>

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151030/be9648ef/attachment.html 

From rory.odonnell at oracle.com  Fri Oct 30 11:13:15 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 30 Oct 2015 15:13:15 +0000
Subject: [wildfly-dev] Early Access builds for JDK 8u72 b05 ,
 JDK 9 b88 and JDK 9 with Project Jigsaw build b86 are available on
 java.net
Message-ID: <5633890B.4000003@oracle.com>


Hi Jason/Tomaz,

Early Access build for JDK 8u72 b05 <http://jdk8.java.net/download.html> 
is available on java.net, summary of changes are listed here. 
<http://download.java.net/jdk8u72/changes/jdk8u72-b05.html?q=download/jdk8u72/changes/jdk8u72-b05.html>

Early Access build for JDK 9 b88 <https://jdk9.java.net/download/> is 
available on java.net, summary of  changes are listed here 
<http://download.java.net/jdk9/changes/jdk9-b88.html?q=download/jdk9/changes/jdk9-b88.html>.

Early Access build for JDK 9 with Project Jigsaw b86 
<https://jdk9.java.net/jigsaw/> is available on java.net.

Changes for JDK 9 with Project Jigsaw b86 : -

  *   New options for the jdeps tool: -genmoduleinfo to generate draft
    module-info.java files, and -ct to do a compile-time analysis of
    references (i.e., follow all references leaving all classes in each
    referenced JAR file) rather than the default run-time analysis
    (which only follows references leaving referenced classes).
  *   jlink no longer does service binding by default.
  * Class::getPackage fixed to return null for array types, primitives,
    and void (bug reported by Chris Newland).
  * Improved messages in IllegalAccessExceptions thrown by core reflection.
  * java -verbose now works with -Xpatch .
  * The special token ALL-SYSTEM can be used with the -addmods option to
    add all system modules.
  * New methods Module::{addUses,canUse}, which are dynamic equivalents
    of service-use clauses in module declarations.

Rgds, Rory

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20151030/0eb1b2c0/attachment.html