On 01/04/15 17:00, Alex Kosowski wrote:
>> on accessing a resource where an authorization decision is made a
>> mapping will be performed to map from the authenticated identity to
>> the roles.
>
> So, the distinction here is that the roles are not stored in the
> Subject, but determined at the last minute?
+1 When it comes to roles in EE today those roles are effectively the
String values potentially compiled into a single deployment so IMO they
are specific to that deployment - once you have requests that pass to
different deployments you now have the problem that the roles are not
portable, or even worse different deployments could have used the same
names with a very different meaning.
Something else that I also believe is not adequately covered is where
accounts may be defined in different stores, an authenticated identity
would always be associated with it's store but the role mapping on
authorization would give much greater flexibility in how these could
work together.
> The advantage being that changes in the role assignments would be seen
> immediately?
>
> Thanks,
> Alex
>
> On 3/31/15 11:31 AM, Darran Lofthouse wrote:
>> On 30/03/15 11:52, arjan tijms wrote:
>>> Hi,
>>>
>>> On Mon, Mar 30, 2015 at 3:02 AM, Alex Kosowski <alex.kosowski_at_oracle.com
>>> <mailto:alex.kosowski_at_oracle.com>> wrote:
>>>
>>> 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?
>>>
>>>
>>> Actually, it holds for any container that doesn't mandate group-to-role
>>> mapping. This can indeed be like GlassFish (which I think doesn't have
>>> default one-to-one, but has it as option), but also for containers which
>>> don't have group-to-role mapping at all. Some containers are a bit of a
>>> hybrid. If I'm not mistaken JBoss uses the "groups" that JASPIC returns
>>> directly as "roles", but optionally they do have some functionality for
>>> some mapping. It's subtly different from having a group to role mapping
>>> that just defaults to one-to-one.
>>
>> At the moment our intentions within WildFly are still to continue with
>> a default 1:1 mapping between groups and roles where use 'groups' to
>> describe the 'thing' loaded just after authentication and 'roles' to
>> be the item checked when making an authorization decision.
>>
>> However our intention is to take this one step further so that an
>> authenticated identity is always associated with the realm that
>> created it, that identity will have the set of groups associated with
>> it - however on accessing a resource where an authorization decision
>> is made a mapping will be performed to map from the authenticated
>> identity to the roles.
>>
>>> On the same subject, I think I saw that since WebLogic 12.1.3
>>> group-to-role mapping defaults to one-to-one (but I have to double check
>>> this).
>>>
>>> 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?
>>>
>>>
>>> Right, this is often the case indeed.
>>>
>>> However, group-to-role mapping itself doesn't seem to be really mandated
>>> anywhere. It's not even specified that it exists and should be taken
>>> into account (in a proprietary manner). JASPIC of course strongly hints
>>> at it by the terminology it uses: *Group*PrincipalCallback.
>>>
>>> The principals that the authentication runtime (JASPIC extension of
>>> Servlet) puts into the Subject can be interpreted by the server's
>>> default JACC provider (the provider that by defaults ships with the same
>>> server) in any way that provider wants, and this includes not requiring
>>> any mapping. This all does make things more difficult for custom JACC
>>> providers, since they don't know how to interpret the "group" Principals
>>> in the Subject.
>>>
>>> Frankly, I'm not entirely sure why we so desperately needed container
>>> specific representations of Principals in the first place, but I guess
>>> that's mostly a history thing.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>> 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}
>>>>
>>>> Seehttp://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)
>>>
>>>
>>