Hi,
Thanks for the replies you all.
To get down to business, the interface as currently proposed looks like
this:
public interface SecurityContext {
Principal getCallerPrincipal();
boolean isCallerInRole(String role);
AuthStatus authenticate(HttpServletRequest request, HttpServletResponse
response, AuthenticationParameters parameters);
AuthStatus authenticate(HttpServletResponse response,
AuthenticationParameters parameters);
}
There's various things to discuss here, such as the return types
(AuthStatus now for authenticate(), and Principal for
getCallerPrincipal()), and the way parameters are provided (via
AuthenticationParameters), as well as the need for passing in the request
and response,
Example usage for the authenticate method:
@Inject
private SecurityContext securityContext;
[...]
AuthStatus status = securityContext.authenticate(
request, response,
withParams()
.credential(credential));
if (status.equals(SEND_CONTINUE)) {
// Authentication mechanism has send a redirect [..]
context.responseComplete();
} else if (status.equals(SEND_FAILURE) {
// [...]
}
Kind regards,
Arjan Tijms
On Sun, Mar 19, 2017 at 8:03 AM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
wrote:
> Hi,
>
> I think Arjan sums it up pretty well and I agree with him and Werner that
> it would be good to fit it into 1.0.
> From a developer's perspective, it can be really confusing not having a
> common platform-wide Security Context.
>
> Ivar
>
> On Sun, Mar 19, 2017 at 12:30 AM Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Arjan/all,
>>
>> Thanks, I think you covered most of the arguments.
>> So on the question how strong I personally feel about it, I assume Arjan
>> also agrees it would be good to try get it into 1.0.
>>
>> Proprietary quasi-standards like Spring Security offer this and it even
>> contains an element called SecuritContext:
>> http://docs.spring.io/spring-security/site/docs/3.0.x/
>> reference/technical-overview.html
>> Since 3.0 so it's been there quite a while.
>>
>> If it won't make it into Security API 1.0 the question would be, how soon
>> the next version (likely a new JSR Security 1.x) could be expected. Similar
>> with Java EE 9. Oracle hopes to introduce annual release trains for Java SE
>> pretty soon, but I am not sure, if even a more Agile way of working and
>> finer grained "profiles" than Java EE has right now will really get us to a
>> new version every year and products picking it up so rapidly.
>>
>> Kind Regards,
>>
>> Werner
>>
>>
>> On Sun, Mar 19, 2017 at 12:15 AM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>> Hi,
>>
>> Maybe one important question to start with; is there any kind of
>> functionality, security context or otherwise, that can still be added at
>> this point, or is because of the tight schedule and low availability of
>> resources taking what's there now (maybe tuning it a little) the only
>> really reasonably option?
>>
>> I'm asking since there are still some major things on the shelve, like
>> the authorization rules, and the multiple authentication mechanisms. A
>> while back Darran Lofthouse proposed the latter, but we haven't heard from
>> him since.
>>
>> I prototyped the authorization rules and it actually works pretty well
>> already, but some discussion about it would not hurt.
>>
>> >and doesn't work on Tomcat because HttpServletRequest isn't injectable.
>>
>> It was, of course, never the idea to depend on HttpServletRequest here.
>> That aside, isn't HttpServletRequest injectable or obtainable (via the
>> BeanManager) if a CDI implementation is added to Tomcat? Or are you
>> referring to the TomEE (not Tomcat) bug here where the injection
>> doesn't quite work as it should?
>>
>> >But I think it still requires significant work,
>>
>> I'm not exactly sure if the amount of work is still significant, but
>> obviously that's a relative term. What would you approximately consider a
>> significant amount of work expressed in time? Would it be e.g. 10 hours
>> (discussion, spec, programming), 20 or something else?
>>
>> Just trying to get some ballpark estimate here so we can hopefully better
>> schedule things around that.
>>
>> Also, quite important, what is the work you think would be required?
>>
>> Specifying an interface with getCallerPrincipal(), isCallerInRole() and
>> authenticate() is not that much work, and the interface is even already
>> there. Or are you referring here to a discussion about the finer details,
>> like returning Principal vs CallerPrincipal, and e.g. the way options are
>> passed into the authenticate() method?
>>
>> > 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.
>>
>> The way to trigger authentication, possibly involving caller interaction,
>> in a web module is done by layering on the servlet mechanism, there's
>> no concept of that in JASPIC. JASPIC only defines how the Servlet
>> Container should call (eventually) a SAM when the application has asked for
>> authentication (has triggered the chain).
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>> On Sat, Mar 18, 2017 at 9:40 PM, Will Hopkins <will.hopkins_at_oracle.com>
>> wrote:
>>
>> 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>
>> 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
>>
>>
>>
>> --
>> Will Hopkins | WebLogic Security Architect | +1.781.442.0310 <(781)%20442-0310>
>> Oracle Application Development
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>>
>> --
>
> Java Champion, JCP EC/EG Member, JUG Leader
>