Hi,
If JSR 375 could force implementations to register a custom provider, that
could be a workaround for the majority of needs. It wouldn't be the
ultimate solution either.
In case that can't be done (because of some kind of JSR restriction), could
be play a bit with the wording on the spec to get a similar result? For
example, saying in JSR 375: "a complaint implementation must provide
methods XXX an YYY which MUST interact with the underlying JACC system".
Then Soteria could to do it via a custom provider and other vendors could
choose to do it in a different manner. Still a workaround, but maybe more
feasible.
Do you think this is worth asking for advice in the Platform mailing list?
Regards,
Guillermo González de Agüero
On Sat, Jul 2, 2016 at 10:04 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi
>
> Thanks for starting this discussion. The current way to register a JACC
> provider is indeed too difficult . This was discussed a while ago as well,
> see
> https://java.net/projects/jacc-spec/lists/users/archive/2015-03/message/0
>
> In the current climate, a MR is not the easiest thing, unfortunately. Ron,
> what do you think?
>
> Alternatively, JSR 375 could provide a standard compliant JACC provider
> and then *demand* Java EE implementations to have this install by default.
> I don't know if this is feasible. Again a question to Ron; would you think
> this is reasonable or even allowed for a JSR to do?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> On Sat, Jul 2, 2016 at 8:25 PM, Guillermo González de Agüero <
> z06.guillermo_at_gmail.com> wrote:
>
>> Hi,
>>
>> I need to register my own JACC provider to change the default security
>> behaviour of my application. Problem there's no standard mecanism to
>> register a custom provider, and moreover, vendor specific mechanisms are
>> incredibly difficult to use[1].
>>
>> I would like to have an option to register a custom JACC provider from a
>> web module, just like we can already register a SAM. This could be a
>> workaround for [2] and would facilitate JSR375 Security Spec to provide a
>> more integrated solution.
>>
>> This change should be done in a MR and included in Java EE 8.
>>
>>
>> Regards,
>>
>> Guillermo González de Agüero.
>>
>> [1]
>> http://arjan-tijms.omnifaces.org/2015/01/java-ee-authorization-jacc-revisited.html
>> [2] https://java.net/jira/browse/SERVLET_SPEC-157
>>
>
>