Hi there,
On Wed, Jan 21, 2015 at 1:52 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
wrote:
> I guess such a property might be optionally set by JAX-RS runtimes and
> possibly accessed via a would be mechanism for accessing the request
> properties inside the service implementation.
>
Possibly, for those cases where JAX-RS is running completely standalone.
> (see
>> http://arjan-tijms.omnifaces.org/2014/03/implementing-
>> container-authorization-in.html)
>>
>> Also note that JAAS is probably not the universal standard you may think
>> it is.
>>
>
> If you re-read my email you will see I actually expressed the concern
> about the explicit use of JAAS API, why do you assume I may have such an
> opinion?
>
Well, since it actually goes a bit further than just the existence of
non-JAAS mechanisms. It's one thing if JAAS is used or not, but even if
JAAS is used (in some form or shape), you can't depend on it for many
things that may seem completely standard.
This basically stems from the fact that JAAS was originally developed for
Java SE, and by itself doesn't match well with the Java EE model where
there is one user/caller principal and zero or more roles. JAAS just
doesn't have a dedicated representation for this.
So, for the last 10 years or so solutions have been introduced that more or
less connect JAAS to Java EE, which are JASPIC (authentication) and JACC
(authorization). But then people ask about using JAAS directly (no JASPIC,
no JACC), which basically would bring you back to square one (i.e. the
situation as it was in 2003).
Sure. In the end of the day I reckon it might help the interested JAX-RS
> users if there was some text adding some clarity and possibly some kind of
> API support for accessing Subject if it will be accepted to be relevant...
>
For Java EE this IMHO doesn't have to be that complex really. I'd say just
being able to inject the current Subject, and then standardizing the
caller/user and group/role principals would really be it. Having access to
these is relevant for at least plain Servlet code, JSF, general CDI beans,
EJB and JCA.
E.g.
@Inject
Subject subject;
...
// Set should likely always be of size 0 or 1
Set<Principal> callerPrincipals =
subject.getPrincipals(javax.security.CallerPrincipal.class);
// Size of set can be 0 or larger
Set<Principal> rolePrincipals =
subject.getPrincipals(javax.security.GroupPrincipal.class);
Kind regards,
Arjan Tijms
>
> Sergey
>
>
> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> Sergey
>>
>>
>>
>
>