Hi,
I also provided an example / proof of concept implementation for the
hasAccessToWebResource method as proposed in the SecurityContext issue. It
was relatively straightforward.
See:
https://github.com/javaee-security-spec/soteria/commit/8f910c0684ed8c38cf7c1ff99cfbd69699a7acdb
@Darran, should you read this, while coding up the proof of concept I
noticed no Permission instances are created for the annotation variant of
an http constraint in WildFly 10.1, e.g.
@ServletSecurity(@HttpConstraint(rolesAllowed = "foo"))
The equivalent variant in web.xml does cause those permissions to be
created in a Policy.
Kind regards,
Arjan Tijms
On Mon, Mar 20, 2017 at 7:52 AM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Mon, Mar 20, 2017 at 1:15 AM, Will Hopkins <will.hopkins_at_oracle.com>
> wrote:
>
>> Well, yes and no. We aren't obligated to implement for every vendors'
>> server, but we do have an obligation to not specify something that would
>> extremely hard to implement in some vendors' containers.
>>
>
>
>
>
>
>> But I wasn't thinking so much about other vendors as I was containers for
>> other application types.
>>
>
> Ok, well, what I meant is that the issue for the context (
> https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12) shows a diagram
> listing about 6 or 7 existing ways to get the user/caller principal and
> test the roles.
>
> Since they are existing ways, the calls are possible and not hard to do
> (since they already exists).
>
> About half of these calls internally fall back on HttpServletRequest#getUserPrincipal,
> the others have some unique code (especially the EJB variant).
>
> The main purpose of the SecurityContext is to unite these calls and become
> a gateway for at least these 2 calls.
>
> We know that the call itself is not difficult or impossible to implement,
> so the other thing that's potentially difficult is the new aspect; which
> container are we in?
>
> Essentially this is what the vendor's container code already does as well
> indirectly, since given e.g. an EJB SessionContext, it internally grabs
> some TLS value or initialised the context with such value when that
> SessionContect is injected for the first time. Right there it checks the
> context (which container the code is running in).
>
>
>
>> Sure, caller principal will be available; caller roles are probably less
>> certain, though, and, in any case, this is additional work that must be
>> done, at least for the Glassfish RI.
>>
>
> Testing for caller roles (isCallerInRole) is certainly available, at least
> in the 7 or so existing APIs that the SecurityContext seeks to unite.
>
>
>
>
>> A small SPI interface that's not currently specified.
>>
>
> It is now ;) Well, at least a proposal for it. Naturally it may need some
> changes still.
>
>
>
>> The concern I have isn't that SecurityContext isn't feasible or a good
>> idea, just that completing it is a non-trivial effort.
>>
>
> I can understand that, but IMHO we also shouldn't be afraid to put in some
> work. I know though that just finalising and providing TCK tests for what
> we essentially had during JavaOne is work too.
>
>
>
>
>> I haven't had time to fully understand the implementation, but it
>> appeared to also depend on passing data back and forth between the calling
>> context and the configured SAM, which must understand the implied contract
>> and adhere to it. Some of the JASPIC types are exposed (AuthStatus at a
>> minimum), and the message-processing model (handling of SEND_SUCCESS,
>> SEND_FAILURE, and SEND_CONTINUE).
>>
>
> It is, but it also isn't. There's not really any new semantics here, as
> the existing 3 outcomes of HttpServletRequest#authenticate (false, true,
> exception) essentially ask the application to handle the exact same
> semantics.
>
> It's not so much that JASPIC has to be understood now, but that the
> existing outcomes are mapped to names. As this seems to continue to cause
> confusion, and since we already opted for this earlier, I'll change the
> JASPIC status codes to a new enum at my earliest possible opportunity.
>
>
>
>> Implying that SecurityContext.authenticate() is only usable when a HAM is
>> configured, which makes the API seem rather narrowly targeted.
>>
>
>
> This is a good point. SecurityContext.authenticate() itself works with any
> authentication mechanism (native, JASPIC, and Security API), but indeed the
> options only target Security API authentication mechanisms (HAM).
>
> We could perhaps solve this in 2 ways:
>
> 1. Specify that while the call is portable to all mechanisms, the options
> are not
> 2. Provide a small helper class that can be used by either native
> mechanisms or SAMs to access the options if they wish to support so.
>
>
>
>
>> FORM is a special case; not sure what you mean by the programmatic
>> variant ....
>>
>
> Sorry, with the programmatic variant I meant the application calling
> HttpServletRequest#authenticate or HttpServletRequest#login.
>
> When that was introduced the platform already moved from fully container
> managed (with FORM as exception) to application involvement.
>
> Here, SecurityContext is not asking for any new responsibilities or
> introducing new semantics. It just gives the existing outcomes of
> HttpServletRequest#authenticate names.
>
>
>
>
>> So the application is not expected to respond to SEND_CONTINUE, for
>> example, and prepare to continue the conversation by calling authenticate()
>> again on the next request?
>>
>
> This is largely what already happens. SEND_CONTINUE itself is already
> exposed by HttpServletRequest#authenticate.
>
> If you look at it here:
>
> http://docs.oracle.com/javaee/7/api/javax/servlet/http/
> HttpServletRequest.html#authenticate-javax.servlet.
> http.HttpServletResponse-
>
> then you see:
>
> false - if authentication is incomplete and the underlying login
> mechanism has committed, in the response, the message (e.g., challenge) and
> HTTP status code to be returned to the user.
>
> It's a little cryptic, but it means "authentication is in progress" and
> "the mechanism has taken over the response".
>
> This is a signal for the application not to touch the response anymore.
> Note that a return of "false" here does not mean "failure", but "in
> progress".
>
> As to prepare to continue the conversation, this too already happens. It's
> the application submitting (posting back) to the virtual JSECURITY_CHECK
> URL. Here it essentially says: "continue the existing conversation with the
> data I provided".
>
>
>
>> If so, why expose any of that complexity? The semantics of the existing
>> HSR.authenticate() call would seem to be sufficient ...
>>
>
> As mentioned above, it's almost completely following the existing
> semantics.
>
> There's 1 new option, and that's the ability to specify that a *new*
> dialog is to be started, or an *existing* dialog is to be continued. The
> existing HttpServletRequest#authenticate is vague about this, and we
> wanted to make the SecurityContext version more explicit about this point.
>
>
>
>> It's getting there ... ;)
>>
>
> Great ;)
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>>
>>
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>> . Part of the problem is that I came on as spec lead late in the game,
>>> and missed whatever discussions you all have already had about this.
>>>
>>>
>>>
>>> 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 <%28781%29%20442-0310>
>>>> Oracle Application Development
>>>> 35 Network Drive, Burlington, MA 01803
>>>>
>>>>
>>>
>>> --
>>> Will Hopkins | WebLogic Security Architect | +1.781.442.0310 <%28781%29%20442-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
>>
>>
>