P.s.
An example of security features being introduces cross spec is the ** role
that was introduced with EE 7;
https://community.oracle.com/blogs/swchan2/2013/04/19/role-servlet-31-security-constraint
In that case Servlet, JACC and if I'm not mistaken EJB cooperated
On Fri, Apr 22, 2016 at 5:46 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>
>
>