Hi,
On Fri, Apr 22, 2016 at 5:16 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Based on recent discussion do you see benefit in talking to the Servlet 4
> EG about aspects of authentication and security?
>
Absolutely, this is something I already discussed with Alex before JSR 375
started; that JSR 375 is largely not something that can only exist in
isolation.
Security in Java EE is spread over many specs, which is one of the issues
that made the task more difficult to begin with. At some point we have to
align with the other specs. Since we're now mostly focusing on the
Http/Servlet view, the Servlet spec would be the most important one to
align with (EJB would theoretically be an other one, but since it's being
so de-emphasized the benefit vs cost ratio is not optimal there)
There's already an issue that partially addresses the alignment:
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-19 (maybe we should add
an "alignment epic")
request#authenticate is one example, as a slightly extended version may be
useful to have at a lower level as well. If that would not happen, then we
can work around it as the RI does now (basically, putting parameters in
request scope before the call, then removing them in a finally clause after
the call).
An other example has to be the request#login method, which should
eventually be able to go to our identity store. JASPIC asks the Servlet
spec to let request#authenticate go to a SAM, so in the same way we could
ask the Servlet spec to let request#login go to the identity store in an
environment where JSR 375 is available.
We also have some terminology that we may want to make consistent across
the platform (the Servlet spec now uses "password validation realm" in some
Javadocs, which we could ask to change into "password based identity
store", etc).
So it is hard to predict, if Servlet 4 was able to use any of the outcome
> of this JSR under the Java EE 8 "umbrella" unless both are known to meet
> their goals and deadlines. Where it was possible to "plug into"
> improvements of Servlet 4 here, that would of course be easier.
>
Indeed. For now Servlet still has to adopt the Servlet Container Profile of
JASPIC btw. This was discussed a year and half or so ago. Having this SPI
available by default is quite important for integration purposes (note that
the Servlet spec already recommends to support JASPIC, spec text wise the
only change is to replace "recommended" by "must").
Would Servlet implement an improved request#authenticate we can easily
rebase on that I guess.
Kind regards,
Arjan Tijms
>
> Regards,
>
> Werner
>