Re: Discussion: SecurityContext


Arjan Tijms
 

Hi,

The general use case for the method is letting the application find out whether a caller has access to certain resources and (mainly) adjusting rendering of links based on that.

A specific use case of this is dynamically rendering a menu with links to pages present in an application, based on what a user is allowed to access. Menu entries could be entirely omitted (so the user only sees entries to pages that are accessible, a common case), or could be rendered differently (say in red, or with a lock symbol next to it).

An extremely simplified example of this can be seen in a small demo app we did here: 


When menus are a little bit more sophisticated, there's often a need to know upfront about entire patterns of pages, for example when testing for /admin/* fails we can omit the entire admin sub header including introduction text. Otherwise we would need to see if the user has access to at least one page.

Roles can be used, and they are in practice, but that assumes the rendering code has knowledge of which role corresponds to which resource, something which doesn't allows remain stable and then necessitates updating code at multiple locations.

A use case where the EJB module could use knowledge about this is as mentioned when sending out emails, which is often done from business services. Another one woud be where an EJB module calls an internal (rest) service. I agree that the EJB module needing to know about the web permissions would be far less common, and would even be more practical with a method that, as Will suggested earlier, also took a Principal as input (things like email sending often happens in batches and asynchronously).

A hasAccessTo is an existing method that has been in use with various frameworks in different forms for some time. One of these is our own OmniFaces project, where we have implemented this here in a slightly different variant:


Hope this made it more clear.

Kind regards,
Arjan Tijms









On Thu, Jun 1, 2017 at 1:02 AM, Bill Shannon <bill.shannon@...> wrote:
Using JNDI-style names for resource names would be confusing.

What's the use case for this method in general, and for using this method with a resource that's in another module?

Arjan Tijms wrote on 05/31/17 03:51 PM:
Hi,

On Thu, Jun 1, 2017 at 12:28 AM, Bill Shannon <bill.shannon@...> wrote:
As I read the spec, the resource name is relative to the web module.  If you're not in a web container, what names can you use?  If your app has two war files, which web module is the name relative to?  Presumably the one you're running in, which means it's not useful if you're not running in a web container.  Well, unless the EJB module is exposing web services of some sort.

You're absolutely right, good catch!

Okay, I was wrong here then. When called from another container or "entry point" into the application (not sure what you would call inflow into a JCA connector exactly), you cannot just call that method.

For a next spec release I could imagine a JNDI like namespace prefix, with java:app/[module name] querying for a specific module in the application and java:module being the default for the current module (which would then throw an IllegalArgumentException if called from an EJB module).

E.g.

From an EJB:

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2

/admin
java:module/admin

Throws IllegalArgumentException 

----

From web module app1

/admin
java:module/admin

Queries for /admin for app1, where /admin must be treated equal to java:module/admin

java:app/app1/admin
java:app/app2/admin

Queries for /admin for app1 and app2, where java:app/app1/admin must be treated equal to java:module/admin

Thoughts?

Kind regards,
Arjan Tijms




 




Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.