users@javaee-spec.java.net

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

From: Guillermo González de Agüero <z06.guillermo_at_gmail.com>
Date: Thu, 13 Apr 2017 12:04:05 +0000

El jue., 13 de abril de 2017 13:46, arjan tijms <arjan.tijms_at_gmail.com>
escribió:

> Hi,
>
> On Thu, Apr 13, 2017 at 10:13 AM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> 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?
>

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?

Bur yes, my idea would be that. "Do it the way JASPIC does it, but you are
not mandated to have a certified JASPIC implementation (which were all very
buggy before your work on that)". The security API could be available on
servers that doesn't allow you to register ServerAuthModules, for instance.

In practice, I imagine every implementation will use JASPIC under the hood,
at least for now.

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.

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

>