Hi,

I fixed the tests so they don't throw exceptions anymore after a 403. Using a SNAPSHOT build from January 11, things start to get better now :)

[INFO] common ............................................ SUCCESS [1.422s]
[INFO] basic-authentication .............................. SUCCESS [5.315s]
[INFO] ejb-propagation ................................... FAILURE [5.010s]
[INFO] lifecycle ......................................... FAILURE [3.747s]
[INFO] register-session .................................. FAILURE [4.160s]
[INFO] wrapping .......................................... SUCCESS [3.739s]

ejb-propagation even partially succeeds. The authentication details are available in the public EJB bean (EJB bean without a security interceptor for @RolesAllowed), but access to a protected EJB (EJB bean with the security interceptor) fails.

This looks exactly like the bug in JBoss EAP 6.x. The security interceptor always tries to authenticate with the "security domain", where it expects a proprietary JBoss login module. I think the interceptor should just use the identity of the caller for local calls (calls to local EJB beans).

If I'm not mistaken, the entire reason to consult a security domain for every method call to an EJB bean is for remote EJB beans, not for local ones. I agree, the spec is not clear about this, but I think other servers indeed use the authenticated identity of the caller for local calls. See also the issue logged for EAP 6.x: https://issues.jboss.org/browse/SECURITY-746

lifecycle is also failing, but this should hopefully be rather simple to fix.

register-session may be a bit more tricky. I remember it took the GlassFish guys some effort.

Btw, there are some things that historically failed on JBoss for which I haven't created tests yet, like forwarding and including from a SAM, which are now mandatory for JASPIC 1.1 (but which the TCK probably doesn't test for either).

Kind regards,
Arjan Tijms














On Thu, Jan 9, 2014 at 10:28 PM, arjan tijms <arjan.tijms@gmail.com> wrote:
That's very good news Stefan!

I'll also take a look at the 403/Exception that you mentioned before. Indeed, HttpUnit throws an exception upon a 403 where Drone that I used for the original tests didn't. This will probably also fix a few test breakages.

Kind regards,
Arjan


On Thu, Jan 9, 2014 at 9:06 PM, Stefan Guilhen <sguilhen@redhat.com> wrote:
I've put a PR for a commit that fixes the wrapping tests. Remaining
failures have been analysed and will be fixed soon.

On 01/09/2014 03:32 PM, Arun Gupta wrote:
> Arjan,
>
> 5 test failures have gone down for now, jboss-web.xml is added to them for now.
>
> Arun
>
> On Thu, Jan 9, 2014 at 3:51 AM, Tomaž Cerar <tomaz.cerar@gmail.com> wrote:
>> You can find info about nightly builds here
>> https://community.jboss.org/thread/224262
>>
>> but just wait a bit for new build that is currently building, that one will
>> have changes you want.
>>
>> --
>> tomaz
>>
>>
>> On Thu, Jan 9, 2014 at 12:11 PM, arjan tijms <arjan.tijms@gmail.com> wrote:
>>> Hi,
>>>
>>>
>>> On Thu, Jan 9, 2014 at 12:07 PM, Tomaž Cerar <tomaz.cerar@gmail.com>
>>> wrote:
>>>> Hey,
>>>>
>>>> this PR https://github.com/wildfly/wildfly/pull/5683 was merged
>>>> yesterday, can you check if it fixes any of your problems?
>>>
>>> I'll check it out, thanks! Any convenient place where I can download a
>>> nightly WildFly build?
>>>
>>>
>>>
>>>
>>>>
>>>> --
>>>> tomaz
>>>>
>>>>
>>>> On Wed, Jan 8, 2014 at 11:32 PM, arjan tijms <arjan.tijms@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>>> On Thu, Dec 12, 2013 at 6:57 PM, Stefan Guilhen <sguilhen@redhat.com>
>>>>>> wrote:
>>>>>>> These are all valid points and I agree that our implementation could
>>>>>>> use some improvements. I'll create a document with the points that need to
>>>>>>> be addressed and I propose we discuss them further next week when Pedro
>>>>>>> returns from his vacations.
>>>>>
>>>>>
>>>>> Just wondering if there has been some progress in the meantime. The
>>>>> JASPIC tests unfortunately still don't run at all on WildFly.
>>>>>
>>>>> I do have to update the tests to HtmlUnit though, and check whether
>>>>> there is or isn't an exception after a 403. The original tests were based on
>>>>> Drone and that one didn't threw an exception. GlassFish doesn't return a 403
>>>>> by itself but just a blank response, so that's why I didn't catch this one
>>>>> earlier.
>>>>>
>>>>> Anyway, it would be great if we can work together to get the tests to
>>>>> run.
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev