Hi,
On Wed, Jan 21, 2015 at 12:46 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
wrote:
> I wonder, should the spec have some position about the services trying to
> access an authenticated Subject ? Something along these lines: "if the
> runtime uses JAAS then it has to guarantee Subject.getSubject works; the
> portability of this code might be affected if non-JAAS solution is used to
> authenticate"...
>
In case of a full Java EE server (i.e. unfortunately excluding the web
profile and especially excluding a bare Servlet container), the following
has to be supported, even when the actual authentication mechanism did not
use JAAS:
Subject subject = (Subject)
PolicyContext.getContext("javax.security.auth.Subject.container");
(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. Where it concerns the container proprietary mechanisms (i.e. anything
that's not JASPIC), it's usually something -based- on JAAS. Specifically,
the Principals that are stored within a Subject are not standardized in any
way (see
http://arjan-tijms.omnifaces.org/2014/02/jaas-in-java-ee-is-not-universal.html
)
> I'm still thinking using SecurityContext is the best option for most
> services, but Subject.doAs can be a pretty useful mechanism to get a
> security context propagated down to JAAS-aware service dependencies, so
> perhaps there's some scope here to support it...
>
Subject.doAs has a lot of side-effects and caveats. It's not really ideal.
But getting the "whole chain" of security streamlined in Java EE is
something that the Security API JSR should really take a look at. Since
this is something that's obviously applicable for many (almost all I'd say)
specs in Java EE, it would probably be best to solve this universally
(platform wide).
Kind regards,
Arjan Tijms
>
> Sergey
>