users@javaee-spec.java.net

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

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Thu, 13 Apr 2017 14:21:27 +0200

Hi,

On Thu, Apr 13, 2017 at 2:04 PM, Guillermo González de Agüero <
z06.guillermo_at_gmail.com> wrote:

> 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?
>>
>
> But, as I understand it (please correct me if I'm wrong), the relationship
> to JACC on the authorization part is basically the same, no?
>

Basically yes indeed, but with a major difference that this does not refer
to the entirety of the JACC spec or even a profile (JACC has no profiles),
but just to a single algorithm that's actually a Servlet algorithm, but
just better (far less ambiguous, far more exact) specified.

So for JASPIC it's a complete profile. Every single bit of the Servlet
Container Profile should be exactly supported. We know that if e.g. the
ordering of methods being called is only a little off, security can totally
fall flat.

For JACC it's only a single algorithm, which is not even JACC's own
algorithm, but originally the one from Servlet (13.8 and specifically
13.8.1). Cutting out even that behaviour dependency is as simple as just
referring to Servlet 13.8.1 instead of JACC.

The only other thing I can think about is having the JASPIC behaviour
reference, but not exposing the javax.security.auth.message package
(specifically the javax.security.auth.message.module.ServerAuthModule type)
in the Web Profile API.

Personally I think it would be quite a lot of trouble on the spec level. If
even Tomcat exposes the javax.security.auth.message package, then why
should it really be a problem for the Web Profile?



> But thinking about adoption in MicroProfile or other small runtimes,
> JASPIC could be effectively be seen as a barrier. I'm mostly thinking about
> it.
>

MicroProfile is obviously important for me personally ;) But there too,
JASPIC should not be a barrier really. People mostly seem to think it is,
thinking it's very complex and thus very big and heavyweight. But in fact
JASPIC is quite small. It's complexity, ironically, comes from it being so
small.

Kind regards,
Arjan Tijms




> I don't know about the relationship about JTA and JTS for example, which I
> guess are in a similar situation where a spec internally requires another
> more low level spec.
>
>
>> 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 <
>>> linda.demichiel_at_oracle.com> escribió:
>>>
>>>> Fellow experts,
>>>>
>>>> We've been receiving some good feedback on the users list
>>>> (jsr366-users_at_javaee-spec.java.net) 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:
>>>> https://java.net/projects/javaee-spec/lists/users/
>>>> 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
>>>>
>>>
>
> Regards,
>
> Guillermo González de Agüero
>
>>