If it's very easy to do or already pretty much done, I agree there is probably no reason to regress.
There is value to having a uniform API for security context to rule them all as opposed to the current distributed mess that's very hard to explain - particularly the one for EJB. Hopefully at some point even the one in Servlet could be deprecated in favor of something more centralized and robust.
-------- Original message --------From: arjan tijms <arjan.tijms_at_gmail.com> Date: 3/16/17 1:50 PM (GMT-05:00) To: jsr375-experts_at_javaee-security-spec.java.net Subject: [javaee-security-spec users] [jsr375-experts] Re: Drop SecurityContext from the spec?
Hi,
The original vision for security context was really simple. Basically just isCallerInRole and getCallerPrincipal.
In fact it's basically done. There's some discussion regarding how to implement it, especially in the light of the "fear" (for lack of a better term) of JACC. But that shouldn't really stand in the way of the specification.
All the other methods and features mentioned in the issue were pretty much optional (nice to haves).
So if we take what we have now, declare that to be the draft spec and invite the EG to provide comments for minor adjustments at most (no new features, but perhaps change the names or option syntax somewhat), then we should be there.
I can try to do the GF implementation soon.
Kind regards,Arjan Tijms
On Thursday, March 16, 2017, Will Hopkins <will.hopkins_at_oracle.com> wrote:
Hi All,
I'm wondering if it makes sense to drop SecurityContext from the
spec, for these reasons:
As currently specified, it is completely redundant. It does
provide a uniform syntax across containers, but all three
methods (one of which only works in the servlet container)
duplicate functions that already exist, albeit with slightly
different syntaxes, in every container. The only value we're
adding here is syntactical uniformity.
As currently specified, SecurityContext provides only a subset
of the functionality originally envisioned. I confess I'm not as
familiar with the earlier plans as I should be, but based on
more recent discussions it seems clear that the original vision
was for a more complete set of functions. It might make sense to
avoid specifying any of the functions until we can consider the
API more completely and wholistically and ensure that it
presents a concise and cohesive set of functions.
The EE 8 schedule is very aggressive. SecurityContext isn't
extremely complicated, but there is still significant work to
finalize the spec and the API, make sure the RI is correct, and,
for us here at Oracle, integrate the RI with GlassFish and
develop the TCK. I think it's still possible to get all that
done for SecurityContext, but in light of the fact that
SecurityContext doesn't add any net-new functionality, I think
it makes sense to drop SecurityContext so we can focus
completely on getting HttpAuthenticationMechanism and
IdentityStore done. Those two pieces add a lot of value, and is
still significant work to do for them, particularly
IdentityStore.
Let me know what you think.
Regards,
Will
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803