Hi,
On Tue, Oct 4, 2016 at 2:46 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Great to hear. It hasn't been a strong focus there so far, but being among
> those hoping for a "Microprofile" somewhere under Java EE (or next to
> it?;-) IBM and its co-collaborators there will certainly appreciate to hear.
>
I hope so to too ;)
But credit where credit is due, IBM (specifically Alasdair and Paul) have
been exceptionally helpful in getting Soteria to run on Liberty by fixing
issues and removing road blocks. Without their help it wouldn't have been
possible, so a big thanks to them!
Looking at the JSR detail page:
https://jcp.org/en/jsr/detail?id=375
> H1 2017 Final Release
> was actually not that wrong after all;-)
>
We're actually in pretty good shape. Still some issues to overcome, but
generally looking good with respect to the authentication epic. TomEE
support is nearly there as well (one of the last blockers is a very low
level but important detail reported here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60196)
The authorization epic is a bit more difficult. I put quite an amount of
time into a prototype for custom authentication rules, but Java EE lacks an
easy to use hook into its authorization machinery. JBoss, GlassFish and
Liberty have such hooks, but you can't use them from within a .war. You
*have* to install a container side module for that. Now principally JSR 375
has to run as a container module anyway, but this does make testing and
demonstrating a lot more difficult. Tomcat doesn't have the hooks we need
at all (although some of the Tomcat roadmap plans did state they wanted to
look into it). Since Tomcat doesn't have those hooks for the Servlet
container, by extension TomEE doesn't have them either.
I've been trying for a long time to get an API for this hook in Java EE,
but I'm not really getting anywhere. And, even if this API would be
introduced, it would of course not have any effect on the existing Java EE
7 servers on which we'd like to test.
> However, unless at least EDR 1 goes out within a month from now (target
> was originally Q1 2015) the next Renewal Ballot at the end of November
> alongside nearly half a dozen other Java EE JSRs is inevitable.
>
As I understood, it's really only the spec lead (Alex) who can submit this,
right? Perhaps worth a try to contact him again and ask if he wants to
submit what we have prepared?
Kind regards,
Arjan Tijms
>
> Several experts have confirmed JSR 375 talks between now and H1 or Q1
> 2017. Ivar should be in Kiev this month. Rudy (I am also invited with other
> JSRs, might join him if the talks are close enough together) was invited to
> Java2Days in Sofia next month. And at least JavaLand also accepted his talk
> (it looks like at least 2 were proposed in parallel, good they picked one,
> not just MVC;-)
>
> I proposed another session to Codemotion Rome and was proposed as
> co-speaker on JSON JSRs for Codemotion Amsterdam, so probably will also
> offer JSR 375 (anybody wanted to join in on that, CFP is open till the
> 21st. Given Java is not the only language relevant to Codemotion, it seems
> more sensible to do a joint proposal by 2, max 3 EG members than several
> competing proposals on the same JSR there)
>
> Kind Regards,
>
> Werner
>
>
> On Sat, Oct 1, 2016 at 7:52 PM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
>> Hi,
>>
>> These are great news! Portability will make it easier for early adopters
>> to test it. And also glad to see the IBM team is hearing and helping.
>>
>> Keep doing this great work, Arjan and all.
>>
>>
>> Regards,
>>
>> Guillermo González de Agüero.
>>
>>
>> On Sat, Oct 1, 2016 at 4:36 PM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I just added support for Liberty to Soteria and added it to the test
>>> targets.
>>>
>>> See: https://travis-ci.org/javaee-security-spec/soteria/builds/164267239
>>>
>>> For this I used a proprietary feature of Weld where it's possible to do
>>> the per-request setup somewhat earlier. Weld will make sure that when the
>>> container (Liberty here) also asks for this initialisation later on, it's
>>> properly ignored, but does record the request. When the container then
>>> later on asks to destroy the per-request setup, it's again ignored so that
>>> we also have the opportunity to destroy it later.
>>>
>>> I introduced a small SPI for this that vendors can optionally implement.
>>> For now I used reflection to call the Weld API if the server is detected to
>>> be Liberty. It looks as follows:
>>>
>>> @Override
>>> public void init(HttpServletRequest request) {
>>> Object weldInitialListener = request.getServletContext().ge
>>> tAttribute("org.jboss.weld.servlet.WeldInitialListener");
>>> ServletRequestEvent event = new ServletRequestEvent(request.getServletContext(),
>>> request);
>>>
>>> ELProcessor elProcessor = new ELProcessor();
>>> elProcessor.defineBean("weldInitialListener",
>>> weldInitialListener);
>>> elProcessor.defineBean("event", event);
>>> elProcessor.eval("weldInitialListener.requestInitialized(eve
>>> nt)");
>>> }
>>>
>>> I also had to disable the DB identity store test for Liberty, since it
>>> depends on an embedded datasource which Liberty does not support.
>>>
>>> Further more, I had to disable the custom form tests for Liberty. It
>>> depends on the HttpServletRequest#authenticate call, which the current
>>> version of Liberty (16.0.03 and 2016.9) does not support (but Paul from the
>>> Liberty team has internally implemented this so it should be available in a
>>> next version).
>>>
>>> Finally, a hack was needed for the form authentication. This makes use
>>> of request wrapping, which unfortunately is also not well supported in
>>> Liberty (but here too, Paul is already looking at it).
>>>
>>> Most importantly, all other tests do run flawlessly, so the majority of
>>> the implementation of JSR 375 now runs on Payara, JBoss (WildFly) and
>>> Liberty. It should also be possible to run it on TomEE (although it too
>>> currently doesn't support request.authenticate), and even on Tomcat with a
>>> CDI implementation separately added.
>>>
>>> Do note that from a spec viewpoint the RI implementation itself doesn't
>>> necessarily has to be portable, but I think it's a nice property that it
>>> largely is.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jsr375-experts+unsubscribe_at_googlegroups.com.
> To post to this group, send email to jsr375-experts_at_googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%
> 2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAAGawe1QSBRJyaUaKNMptnt_%2BReRUr9y2diF19DXOqDWQ-FKMA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>