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
>
>