I can see how this would be useful (although I don't see how we get to
@RunAs based on getCallerPrincipal() or getCallerInRole() alone).
My objection isn't to the functionality, it's to the effort required to
complete the SecurityContext work, in light of the fact that there are
existing ways to achieve the same thing, albeit with different syntax in
different containers.
The spec and the API are the easy parts, relatively speaking, but there
is still RI and TCK work required. I just had a look at the impl in
Soteria, and it's servlet-container-only at this point, and doesn't work
on Tomcat because HttpServletRequest isn't injectable. Extending
SecurityContext to other containers would presumably require the ability
to inject appropriate context objects from those containers as well --
possibly limiting the containers for which SecurityContext could be
supported -- or a non-CDI-based integration approach). Having just
looked at the RI impl of authenticate, I'm also wondering about the
level of dependence on JASPIC, vs. a simple layering on the servlet
mechanism.
All of this is not to say that we can't include ServletContext, or that
it doesn't have value. But I think it still requires significant work,
and given how tight the remaining schedule is, I'm concerned about
investing that effort in functionality that's redundant to some degree,
and could be undertaken, more thoughtfully, in the next security JSR.
The HttpAuthenticationMechanism and IdentityStore, by contrast, feel
much better defined to me, although there are still some details to work
out.
Arjan, Werner: How strongly do you feel about SecurityContext?
Other experts: Any thoughts on this, one way or another?
Will
On 03/16/2017 02:20 PM, Werner Keil wrote:
> I just did a presentation at the current client today about the state
> of Java EE 8.
>
> And like several other gigs before, there are plenty of use cases with
> something like
> @RunAsUser(username="abc", department="xyz")
> or similar.
>
> I'm not sure, if we manage to provide something like those kinds of
> annotations, they often can get pretty domain or company specific, but
> an underlying isCallerInRole or getCallerPrincipal mechanism would be
> a start to use and create them in a standard manner.
>
> If there was a strong disagreement on naming or what should be there,
> I could understand leaving it for later, but if that's not the case, I
> would try to leave it and provide basic implementations. Maybe more to
> follow in EE 9 or leave it up to individual products.
>
> Regards,
>
> Werner
>
>
>
> On Thu, Mar 16, 2017 at 6:50 PM, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> 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
> <mailto: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 <tel:+1%20781-442-0310>
> Oracle Application Development
> 35 Network Drive, Burlington, MA 01803
>
>
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803