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

From: arjan tijms <>
Date: Thu, 13 Apr 2017 13:46:28 +0200


On Thu, Apr 13, 2017 at 10:13 AM, Guillermo González de Agüero <> wrote:

> Hi Linda,
> Arjan said he thinks the JASPIC dependency can be removed from the spec. I
> hope he can confirm this. That would solve the only real problem people
> seems to have.

I'm going to try to remove the compile time dependencies from the API
indeed. This should basically mean that the MessageInfo map and the
AuthException will be removed. I'm thinking of making MessageInfoMap an
Object (people have to cast then) and AuthException will become a JSR 375
owned AuthenticationException.

Personally, I'd prefer not to include JASPIC on the Web Profile. Not
> because it is bad, but because it is a complicated technology thar people
> will barely use having the new
> Security API.

I'm personally not that much concerned about it. It's not full JASPIC but
only the Servlet Container Profile that has to be added.

About the complexity of standalone JASPIC; the ServerAuthModule would have
been really the only artefact users would normally use. For a lower level
artefact it's not that crazy complicated, but it's indeed not focussed so
much an application developers.

By still having JSR 375 depend on JASPIC for behaviour, a compliant Web
Profile implementation would still have to support the Servlet Container
Profile of JASPIC, so I think the difference in practice is quite small.

> But for that to be true, the Security API has to be present.
> Given that every Servlet container now supports JASPIC and even the
> Servlet spec once considered to require the presence of JASPIC, I think
> there will be no difference at all for end users.

Indeed, that's the point pretty much.

> - If possible, remove its hard reference from the spec. Only mandate to
> use it underneath on thd Full edition. Arjan will need to confirm if this
> is possible.

Removing compile time dependencies should be possible, but not mandating
using JASPIC on anything but the full edition would not work.

The problem is that JSR 375 would have to specify all the behaviour,
ordering, timing etc when all of its methods are called. So currently we
say for e.g. the validateRequest method: see JASPIC.

If we say: on the full profile, use JASPIC, on the Web Profile, use
"whatever" to implement it, how would implementors know what behaviour to
implement? We didn't specify that in JSR 375.

So the only way would be to do exactly what JASPIC does, without it having
to actually be JASPIC. But if you already have to do exactly what the
Servlet Container Profile of JASPIC does, then you just have the Servlet
Container Profile of JASPIC, haven't you?

Kind regards,
Arjan Tijms

> - If not possible to remove the dependency, bring JASPIC to the Web
> Profile. I doubt it will make any difference in practice, at least on the
> short term.
> Regards,
> Guillermo González de Agüero
> El jue., 13 de abril de 2017 1:28, Linda DeMichiel <
>> escribió:
>> Fellow experts,
>> We've been receiving some good feedback on the users list
>> ( regarding the inclusion of the
>> Java EE Security API. I hope all of you have been following the
>> discussion. If not, the users list archives are here:
>> archive/2017-04/thread/1
>> In short, support for including the Java EE Security API in the full
>> platform has been unanimous, but there has been some disagreement as
>> to whether the Security API should be included as part of the Web
>> Profile, largely due to its dependence on JASPIC.
>> I would appreciate if you would weigh in on this issue.
>> thanks,
>> -Linda
>> On 4/7/17, 3:11 PM, Linda DeMichiel wrote:
>> > The Java EE Security API has received strong support in the community
>> > and has been making good process as evidenced by its recent Early
>> > Draft. This JSR is now on-track to complete within the Java EE 8 time
>> > frame.
>> >
>> > We believe that the Java EE Security API adds value to the Java EE
>> > Platform due to its simplifications and enhancements to platform
>> > security, and should be included as a required technology in both the
>> > Java EE 8 Platform and the Java EE 8 Web Profile.
>> >
>> > Please let us know if for some reason you object.
>> >
>> > thanks,
>> >
>> > -Linda