Hi Arjan,
Response inline.
El jue., 13 de abril de 2017 14:21, arjan tijms <arjan.tijms_at_gmail.com>
escribió:
> 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?
>
Thanks as always for your explanations!
>
>> 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.
>
It's more a marketing issue for me. JASPIC is not heavyweight but is very
daunting and developer unfriendly.
Including won't add any overhead as it's already there. But maybe it has to
be presented in another form. I mean, until today, JASPIC was *the way* to
do container autentication. And unfortunately most people aren't even aware
of it.
Now, having the new API, talking about JASPIC may sound to some people like
a step back. But I think it is a matter of approach. It just has to be
clarified that it has become a foundational base and that people are
expected to use the new one.
That should suffice in my opinion to justify and explain its requirement.
But yes, better to keep it there.
>
> 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
>>
>
Regards
Guillermo González de Agüero.
>