users@javaee-spec.java.net

[javaee-spec users] Re: [jsr366-experts] Java EE Security API

From: reza_rahman <reza_rahman_at_lycos.com>
Date: Mon, 10 Apr 2017 16:38:50 -0400

I actually think what we have now is pretty useful. Given the strong support for security in all the Java EE surveys, I think it sends the wrong message not to include it in the Web Profile. I don't see that there is any future where the security API does not wind up in pretty much all significant Java EE profiles.
-------- Original message --------From: arjan tijms <arjan.tijms_at_gmail.com> Date: 4/10/17 4:13 PM (GMT-05:00) To: users <users_at_javaee-spec.java.net> Subject: [javaee-spec users] Re: [jsr366-experts] Java EE Security API
Hi,

On Mon, Apr 10, 2017 at 9:35 PM, <ondrej.mihalyi_at_gmail.com> wrote:
However, I'd like to ask what are the implications? What other

dependencies would it bring to the WebProfile?



E.g. the Security JSR depends on JASPIC, which is not part of Web

Profile. From the spec EDR1: " Integration with the servlet container

leverages JASPIC;

the container MUST configure and invoke the HttpAuthenticationMechanism

via JASPIC, as

described below"



It seems to me that with the new Security JSR, also JASPIC needs to be

moved to Web Profile. Is it really necessary or can the dependency on

JASPIC be optional?

JASPIC is practically indeed necessary.
Theoretically, but only theoretically, it would not be absolutely needed and could be abstracted by a layer on top of a Servlet container's native ability to add a custom authentication mechanism. 
But that would basically run into a kind of abstraction overflow, as JASPIC is already exactly that abstraction layer. To abstract on top of the abstraction layer would be awkward at best. In the worst case that abstraction layer would end up to be pretty much identical to what the Servlet Container Profile of JASPIC is today; in other words we would have duplicated JASPIC for no real benefit.
Additionally such abstraction would mean Servlet containers would have to support an additional SPI, as this kind of abstraction needs native hooks.
Furthermore, the time required to specify such abstraction layer is not there, as we pretty much have to go final with JSR 375 somewhere in the mid of next week.
A big point is that JASPIC is likely one of the most misunderstood specs in the entire EE landscape. It's not a big chunk of code that's implemented independently (like say JSF or JPA implementations), but it's a set of guidelines and a few interfaces that a Servlet container (for the Servlet Container Profile) must implement/do.
The thing is that every Java EE 7 Servlet container (i.e. including Tomcat and Jetty) already implements JASPIC, and that even the Servlet spec recommends to use the JASPIC SPI for using custom authentication mechanisms with a Servlet container. We *almost* got the Servlet EG to agree to change this one word from something like "recommend" to "mandate", and the Servlet spec is of course a bit lower level than the Web Profile. 
I'd appreciate to make JASPIC optional and leave it out of Web Profile,

because it's a cumbersome API and not really needed to be exposed in

the Web Profile.

It's not so much an API really, but more an SPI that standardises things that a Servlet container already does.
As for being cumbersome, that's where the Java EE Security API comes in, which is an higher level API aimed at application developers. 
But it needs "a hook into the Servlet container", and that hook is not there, other than via JASPIC.
It's slightly comparable with JTS sitting underneath JTA, which provides @Transactional and the default transactional behaviour in EJB beans. Very few to almost no people would descend into low level JTS and not even low level (programmatic) JTA, but the CDI based @Transactional annotation and the EJB variant are very often used and greatly appreciated.
Hope this makes it more clear ;)
Kind regards,Arjan Tijms

 


Ondrej