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> 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> 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 <+1%20781-442-0310>
>> Oracle Application Development
>> 35 Network Drive, Burlington, MA 01803
>>
>>