Hi Arjan,
> But a JASPIC auth module can dynamically return any amount of roles to the container and via HttpServletRequest#isUserInRole() an application can dynamically query for any such role without anything needing to be declared.
You mention JASPIC as returning "roles" in the GroupPrincipalCallback
without requiring role mapping. Isn't that only true for containers
(e.g. Glassfish) which have default one-to-one Group-To-Role mapping?
I think JASPIC just adds group principals to the Subject, but that is
only interpreted as a role if some non-portable server-specific config
is applied (like enabling one-to-one Group-To-Role mapping, or
glassfish-web.xml mapping). Right?
Thanks,
Alex
On 3/17/15 5:44 AM, arjan tijms (JIRA) wrote:
> [ https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=384695#comment-384695 ]
>
> arjan tijms commented on JAVAEE_SECURITY_SPEC-14:
> -------------------------------------------------
>
> {quote}
> I wonder how necessary it is to build on top of the legacy JASPIC/JACC APIs.
> {quote}
>
> How did you came to the conclusion that JASPIC is legacy? It was only introduced in Java EE 6.
>
> If anything, JASPIC is a very low level SPI that introduces interaction points in the Servlet container. These points are not that different from what really modern Servlet containers like Undertow use for their native security system. Now the API that JASPIC uses is very bare, since it's not even specific to HTTP. Compare this to the Servlet interface and the HttpServlet class in the Servlet spec.
>
> The bare JASPIC SPI is a really good foundation to build more user friendly interfaces on top. See e.g. http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
>
> {quote}Related to your comment on JAVAEE_SECURITY_SPEC-8, the existing security model does things like force an app to pre-declare all of their roles and user mappings up front in XML. {quote}
>
> This is not entirely correct.
>
> First of all there is definitely no requirement to pre-declare any kind of user mappings in XML, although I'm not 100% sure what you even mean with "user mapping" (I assume mapping a given user, say "pete" to a given role, say "admin"?). There is nothing in whatever existing spec that requires this.
>
> JASPIC in particularly is fully transparent to this. Inside an auth module you dynamically hand over the user/caller name and optionally a series of role/group names, and that is it. That data will be set as the authenticated user. Via the well known {{HttpServletRequest#isUserInRole()}} an application can dynamically query for any role. There is no requirement or necessity to map or declare anything upfront.
>
> Now there unfortunately is a place that demands upfront declaration of application roles, and that's JACC, or rather the default implementation of an authorization module (called Policy in JACC). Do note that it DOES NOT demand any user mapping, user declaration or whatever. JACC does nothing with all of that.
>
> The only thing that JACC wants to know (and thus what the spec demands to be declared upfront) is the list of application roles, in so far these aren't used within annotations. E.g. it wants to know a list like {{(employee, manager, admin, broker)}}.
>
> Now I agree this is a limitation and I wrote about this before:
>
> {quote}
> Typically JACC providers will create the total list of WebRoleRefPermission instances when an application is deployed and then return a sub-selection based on the Principals that we (indirectly) passed in our call to Policy#getPermissions. This however requires that all roles are statically and upfront declared. But a JASPIC auth module can dynamically return any amount of roles to the container and via HttpServletRequest#isUserInRole() an application can dynamically query for any such role without anything needing to be declared. Unfortunately such dynamic role usage typically doesn't work when JACC is used (the Java EE specification also forbids this, but on servers like JBoss it works anyway).
> {quote}
>
> See http://arjan-tijms.omnifaces.org/2014/03/implementing-container-authorization-in.html
>
> I think it might be possible to get rid of this limitation by having JACC authorization modules respond to role updates, after which they can update the list of WebRoleRefPermission instances I mentioned above. I can already do this today with a custom JACC authorization module.
>
> {quote}I'd also, ideally, like to see this is built in a modular way too that makes parts (all?) of the API something that could possibly be leveraged outside of the app server. {quote}
>
> This is a question that comes up with almost every JSR. Someone even asked for the new MVC spec to be Java SE based! (the spec leads said no in that case though).
>
> At any length, JASPIC is already specified to work with both Java EE and outside Java EE, and to work both from within an application archive and when installed inside an application server.
>
> About that last point, while I'm a big fan of the possibility of having as much as possible specified/configured from within the application archive, we should not forget that there are also many use cases that require configuring security at the application server level. The security frameworks you mentioned (Shiro, Spring Security) are based on Servlet filters and only work from within the application archive. JASPIC auth modules are very much filter-like, but it's a special kind of filter that as mentioned can be used both inside and outside an application archive.
>
>
>> Introduce Concept of Permissions in Authorization
>> -------------------------------------------------
>>
>> Key: JAVAEE_SECURITY_SPEC-14
>> URL: https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-14
>> Project: javaee-security-spec
>> Issue Type: New Feature
>> Reporter: sparty02
>>
>> The notion of a security "role" is far too broad in the context of authorization....especially for a standardized API that should be low-level enough for the ecosystem to build around. All three of the well-established OSS Java security frameworks that I'm aware of (Apache Shiro, Spring Security, and JBoss PicketLink) all support the concept of a permission, as well as a role (a logical grouping of permissions). Both a role and permission should be able to be assigned to a user and they should compose well together.
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.2.3#6260)