Hi,
On Thu, Apr 9, 2015 at 4:05 PM, Darran Lofthouse
<darran.lofthouse_at_redhat.com> wrote:
> 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.
This basically touches the topic of federated identity, right? And
then related to that, federated identity/authentication stores.
>
>
>> 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)
>>>>
>>>>
>>>>
>>>
>