[cdi-dev] Types of Principal object

Wed Apr 26 12:17:30 EDT 2017

Btw. I think some aspects of this thread seem a little off-topic or more
specific to the JSR 375 list instead (or at least it would be good to CC
that one for detailed java.security discussions rather than if a generic
type works or not)

Werner

On Wed, Apr 26, 2017 at 6:11 PM, <cdi-dev-request at lists.jboss.org> wrote:

> Send cdi-dev mailing list submissions to
>         cdi-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
>         cdi-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
>         cdi-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Types of Principal object (arjan tijms)
>    2. Re: Types of Principal object (arjan tijms)
>    3. Re: Types of Principal object (Romain Manni-Bucau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Apr 2017 18:00:40 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] Types of Principal object
> To: Matej Novotny <manovotn at redhat.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhBp8cLUxWOpnT=oyp-h+f2uYDgUvwJDfSkzYjRqha5HHA@
> mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> On Wed, Apr 26, 2017 at 4:48 PM, Matej Novotny <manovotn at redhat.com>
> wrote:
>
> > And spec requires all built-in beans to be decorable - e.g. you need them
> > to be proxyable (although the added value of principal decorator is
> ...eh,
> > disputable at best?).
> >
>
> That would be kinda disputable indeed :O
>
>
> > Therefore, it is safer/viable to create a proxyable wrapper object which
> > implements Principal only and delegetas calls (that's what Weld does).
> >
>
> As i mentioned, the proxy has to be there as just injecting a non-proxy
> Principal would not work correctly. If a logout call is done, the injected
> Principal would still be the principal that it was before, let alone what
> happens if the Principal is inject in application scoped beans...
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > Otherwise I agree it could be nice to ahve a way to cast the object as
> the
> > pure Principal interface doesn't help much.
> >
> > Matej
> >
> > ----- Original Message -----
> > > From: "John Ament" <john.ament at spartasystems.com>
> > > To: "cdi-dev" <cdi-dev at lists.jboss.org>
> > > Sent: Wednesday, April 26, 2017 3:54:57 PM
> > > Subject: [cdi-dev] Types of Principal object
> > >
> > >
> > >
> > > Hey guys
> > >
> > >
> > >
> > >
> > > I raised a bug against the Weld guys, but think its worth an EG
> > discussion.
> > > When a Principal object is injected, the only type it has is Principal.
> > It
> > > does not retain the actual type used at runtime. This threw me off on
> > some
> > > Keycloak integration I'm working on (in $dayjob). So I was wondering,
> is
> > > this expected from our POV or should it retain the types of the actual
> > > runtime instance?
> > >
> > >
> > >
> > >
> > > John
> > >
> > >
> > >
> > >
> > > NOTICE: This e-mail message and any attachments may contain
> confidential,
> > > proprietary, and/or privileged information which should be treated
> > > accordingly. If you are not the intended recipient, please notify the
> > sender
> > > immediately by return e-mail, delete this message, and destroy all
> > physical
> > > and electronic copies. Thank you.
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > code
> > > under the Apache License, Version 2
> > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > > provided on this list, the provider waives all patent and other
> > intellectual
> > > property rights inherent in such information.
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (http://www.apache.org/
> > licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> > the provider waives all patent and other intellectual property rights
> > inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20170426/1b8d735a/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Apr 2017 18:07:52 +0200
> From: arjan tijms <arjan.tijms at gmail.com>
> Subject: Re: [cdi-dev] Types of Principal object
> To: Romain Manni-Bucau <rmannibucau at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CAE=-AhC2YBs0biFaRPpxrpiXy4WTaKU_Xsm+nxSCk3mUkhZYQg at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <rmannibucau at gmail.com
> >
> wrote:
>
> > that's why security API needs a more typed API acting as an handler and
> > not as a contextual instance, it would allow to unwrap the actual
> instance
> > (like most specs do)
> >
>
> I think that would require a new Principal type, which can be done, but
> who's going to put time into it to discuss it, spec it, implement it, etc?
>
> Also, the difference with the current situation is not that much then.
>
> Extended Principal:
>
>
> @Inject CallerPrincipal callerPrincipal;
>
> ...
>
> MyPrincipal myPrincipal = callerPrincipal.unwrap();
>
>
> vs
>
>
> Security context:
>
> @Inject SecurityContext securityContext;
>
> ...
>
> MyPrincipal myPrincipal = securityContext.getCallerPrincipal();
>
> Spot the differences ;)
>
>
>
> > In other words either Principal is removed from CDI spec
> >
>
> I think this should be done anyway. The build-in bean for Principal would
> be more at home with the Security API spec. I would be happy to take it in
> ;)
>
> (likewise, the build-in bean for HttpServletRequest etc should be with the
> Servlet spec)
>
>
>
> > or it stays but it should be extended to be made usable IMHO.
> >
>
> What CDI could provide and which has been discussed before, is a method to
> get the real bean from a proxy. E.g.
>
> @Inject CallerPrincipal callerPrincipal;
> @Inject BeanManager beanManager;
>
> ...
>
> MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2017-04-26 17:11 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
> >
> >> Hi,
> >>
> >> We discussed this very issue in the Security API EG as well. In the
> >> Security API the actual type *MUST* be retained as per the spec
> definition.
> >>
> >> The problem in CDI, at least in Weld, is that a proxy is injected. This
> >> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
> where
> >> AbstractEEBean does:
> >>
> >> public abstract class AbstractEEBean<T> extends
> >> AbstractStaticallyDecorableBuiltInBean<T> {
> >>
> >>     private final T proxy;
> >>
> >>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> >> BeanManagerImpl beanManager) {
> >>         super(beanManager, type);
> >>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> >> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
> >> new CallableMethodHandler(callable)));
> >>     }
> >>     // ...
> >> }
> >>
> >> I'm not even sure if it's possible to downcast the proxy to the required
> >> runtime type.
> >>
> >> Also note that the Principal can change during the request. The simplest
> >> case is when during an http request HttpServletRequest#logout is called.
> >>
> >> Kind regards,
> >> Arjan Tijms
> >>
> >>
> >>
> >>
> >> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
> john.ament at spartasystems.com
> >> > wrote:
> >>
> >>> Hey guys
> >>>
> >>>
> >>> I raised a bug against the Weld guys, but think its worth an EG
> >>> discussion.  When a Principal object is injected, the only type it has
> is
> >>> Principal.  It does not retain the actual type used at runtime.  This
> threw
> >>> me off on some Keycloak integration I'm working on (in $dayjob).  So I
> was
> >>> wondering, is this expected from our POV or should it retain the types
> of
> >>> the actual runtime instance?
> >>>
> >>>
> >>> John
> >>>
> >>> ------------------------------
> >>> NOTICE: This e-mail message and any attachments may contain
> >>> confidential, proprietary, and/or privileged information which should
> be
> >>> treated accordingly. If you are not the intended recipient, please
> notify
> >>> the sender immediately by return e-mail, delete this message, and
> destroy
> >>> all physical and electronic copies. Thank you.
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses the
> >>> code under the Apache License, Version 2 (
> http://www.apache.org/license
> >>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
> >>> provider waives all patent and other intellectual property rights
> inherent
> >>> in such information.
> >>>
> >>
> >>
> >> _______________________________________________
> >> cdi-dev mailing list
> >> cdi-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >> Note that for all code provided on this list, the provider licenses the
> >> code under the Apache License, Version 2 (http://www.apache.org/license
> >> s/LICENSE-2.0.html). For all other ideas provided on this list, the
> >> provider waives all patent and other intellectual property rights
> inherent
> >> in such information.
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20170426/9cd63650/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Apr 2017 18:10:10 +0200
> From: Romain Manni-Bucau <rmannibucau at gmail.com>
> Subject: Re: [cdi-dev] Types of Principal object
> To: arjan tijms <arjan.tijms at gmail.com>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Message-ID:
>         <CACLE=7MCs1XrpCnNjSXSM92aXW31kKLdb1EnmER7Z6MTkGnFXw at mail.
> gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2017-04-26 18:07 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
>
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <
> rmannibucau at gmail.com
> > > wrote:
> >
> >> that's why security API needs a more typed API acting as an handler and
> >> not as a contextual instance, it would allow to unwrap the actual
> instance
> >> (like most specs do)
> >>
> >
> > I think that would require a new Principal type, which can be done, but
> > who's going to put time into it to discuss it, spec it, implement it,
> etc?
> >
> > Also, the difference with the current situation is not that much then.
> >
> > Extended Principal:
> >
> >
> > @Inject CallerPrincipal callerPrincipal;
> >
> > ...
> >
> > MyPrincipal myPrincipal = callerPrincipal.unwrap();
> >
>
> Was more thinking about:
>
> MyPrincipal myPrincipal = callerPrincipal.unwrap(MyPrincipal.class);
>
>
> >
> >
> > vs
> >
> >
> > Security context:
> >
> > @Inject SecurityContext securityContext;
> >
> > ...
> >
> > MyPrincipal myPrincipal = securityContext.getCallerPrincipal();
> >
> > Spot the differences ;)
> >
>
> Here you can get a PrincipalFacade which limits MyPrincipal to getName()
> only, this is perfectly valid per spec.
>
>
> >
> >
> >
> >> In other words either Principal is removed from CDI spec
> >>
> >
> > I think this should be done anyway. The build-in bean for Principal would
> > be more at home with the Security API spec. I would be happy to take it
> in
> > ;)
> >
> > (likewise, the build-in bean for HttpServletRequest etc should be with
> the
> > Servlet spec)
> >
> >
> >
> >> or it stays but it should be extended to be made usable IMHO.
> >>
> >
> > What CDI could provide and which has been discussed before, is a method
> to
> > get the real bean from a proxy. E.g.
> >
> > @Inject CallerPrincipal callerPrincipal;
> > @Inject BeanManager beanManager;
> >
> > ...
> >
> > MyPrincipal myPrincipal = beanManager.unwrap(callerPrincipal);
> >
>
> Well this would assume we can do it for all beans and a lot of cases would
> be problematic cause it is just not doable :s...but would help if we find a
> compromise for other beans too :)
>
>
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> >> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> >> <http://rmannibucau.wordpress.com> | Github
> >> <https://github.com/rmannibucau> | LinkedIn
> >> <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> >> <https://javaeefactory-rmannibucau.rhcloud.com>
> >>
> >> 2017-04-26 17:11 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:
> >>
> >>> Hi,
> >>>
> >>> We discussed this very issue in the Security API EG as well. In the
> >>> Security API the actual type *MUST* be retained as per the spec
> definition.
> >>>
> >>> The problem in CDI, at least in Weld, is that a proxy is injected. This
> >>> happens via the build-in bean "PrincipalBean extends AbstractEEBean",
> where
> >>> AbstractEEBean does:
> >>>
> >>> public abstract class AbstractEEBean<T> extends
> >>> AbstractStaticallyDecorableBuiltInBean<T> {
> >>>
> >>>     private final T proxy;
> >>>
> >>>     protected AbstractEEBean(Class<T> type, Callable<T> callable,
> >>> BeanManagerImpl beanManager) {
> >>>         super(beanManager, type);
> >>>         this.proxy = new ProxyFactory<T>(beanManager.getContextId(),
> >>> type, getTypes(), this).create(new EnterpriseTargetBeanInstance(type,
> >>> new CallableMethodHandler(callable)));
> >>>     }
> >>>     // ...
> >>> }
> >>>
> >>> I'm not even sure if it's possible to downcast the proxy to the
> required
> >>> runtime type.
> >>>
> >>> Also note that the Principal can change during the request. The
> simplest
> >>> case is when during an http request HttpServletRequest#logout is
> called.
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Apr 26, 2017 at 3:54 PM, John Ament <
> >>> john.ament at spartasystems.com> wrote:
> >>>
> >>>> Hey guys
> >>>>
> >>>>
> >>>> I raised a bug against the Weld guys, but think its worth an EG
> >>>> discussion.  When a Principal object is injected, the only type it
> has is
> >>>> Principal.  It does not retain the actual type used at runtime.  This
> threw
> >>>> me off on some Keycloak integration I'm working on (in $dayjob).  So
> I was
> >>>> wondering, is this expected from our POV or should it retain the
> types of
> >>>> the actual runtime instance?
> >>>>
> >>>>
> >>>> John
> >>>>
> >>>> ------------------------------
> >>>> NOTICE: This e-mail message and any attachments may contain
> >>>> confidential, proprietary, and/or privileged information which should
> be
> >>>> treated accordingly. If you are not the intended recipient, please
> notify
> >>>> the sender immediately by return e-mail, delete this message, and
> destroy
> >>>> all physical and electronic copies. Thank you.
> >>>>
> >>>> _______________________________________________
> >>>> cdi-dev mailing list
> >>>> cdi-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>>
> >>>> Note that for all code provided on this list, the provider licenses
> the
> >>>> code under the Apache License, Version 2 (
> http://www.apache.org/license
> >>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
> >>>> provider waives all patent and other intellectual property rights
> inherent
> >>>> in such information.
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cdi-dev mailing list
> >>> cdi-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>>
> >>> Note that for all code provided on this list, the provider licenses the
> >>> code under the Apache License, Version 2 (
> http://www.apache.org/license
> >>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
> >>> provider waives all patent and other intellectual property rights
> inherent
> >>> in such information.
> >>>
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/
> 20170426/1afdba6f/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html).  For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
> End of cdi-dev Digest, Vol 77, Issue 11
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20170426/34158090/attachment-0001.html 