Hi,
On Thu, Apr 9, 2015 at 11:25 PM, Alex Kosowski <alex.kosowski_at_oracle.com> wrote:
> Or are you referring to identity propagation?
Yes, that's related too.
> 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.
I 100% agree, even though federation and propagation are really
important topics, we have to be realistic. It's Q2 2015 already. Java
EE 8 is supposed to come out Q3 2016. Within reason I'd say that's
about a year of time left, the remainder would just be winding down
and reviews etc. I've observed how EGs work for long enough to know
that a year is really not that much time.
Kind regards,
Arjan Tijms
>
>
> 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)
>>>>>>
>>>>>>
>>>>>>
>