Or are you referring to identity propagation? These are topics that I
think are beyond the JSR 375 1.0 API spec. We have some low hanging
fruit I think we should tackle first.
On 4/9/15 4:16 PM, arjan tijms wrote:
> 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)
>>>>>
>>>>>