Hi,
I just provided an implementation of the getAllDeclaredCallerRoles()
method, which returns a List<String> of all current (declared) roles the
caller has.
This was again relatively easy to implement using the standard Java EE APIs.
As discussed earlier, we should probably spec this method to only return
the declared (static) roles. Any dynamic role that the authorization system
may grant the caller should not be in this collection.
See:
https://github.com/javaee-security-spec/soteria/commit/b20ff8fb386015e8760bb93cad4af923bf419a31
Kind regards,
Arjan Tijms
p.s.
This commit flushes out the pending changes in my workspace. I'm going to
do PRs moving forward.
On Mon, Mar 20, 2017 at 11:11 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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/HttpS
>> ervletRequest.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
>>>
>>>
>>
>