+1
Let's try to be focused cause yes federation will also require a lot of
discussions and it's probably also too early
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com
On Thu, Apr 9, 2015 at 11:44 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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)
> >>>>>>
> >>>>>>
> >>>>>>
> >
>