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(a)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.

P.s. slightly offtopic for CDI spec itself, but: A small workaround is to @Inject SecurityContext context; and then: MyPrincipal principal = (MyPrincipal ) context.getCallerPrincipal(); Thinking of it, maybe I can make the getCallerPrincipal() a generic method, so one can do: MyPrincipal principal = context.getCallerPrincipal(); Kind regards, Arjan Tijms On Wed, Apr 26, 2017 at 4:38 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com > wrote: > Hi John, > > agree CDI/security integration (mainly through Principal bean) is > completely unusable in practise cause Principal type is too simple (name > only) and casting is needed in 99.99% of apps. AFAIK It is tracked at > https://issues.jboss.org/browse/CDI-597. > > > 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 15:54 GMT+02:00 John Ament <john.ament(a)spartasystems.com&gt;: > >> 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(a)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(a)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. >

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?).

Therefore, it is safer/viable to create a proxyable wrapper object which implements Principal only and delegetas calls (that's what Weld does).

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(a)spartasystems.com&gt; > To: "cdi-dev" <cdi-dev(a)lists.jboss.org&gt; > 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(a)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(a)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.

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(a)spartasystems.com&gt; 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(a)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(a)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.

Hi, On Wed, Apr 26, 2017 at 5:41 PM, Romain Manni-Bucau <rmannibucau(a)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(a)gmail.com&gt;: > >> 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(a)spartasystems.com&gt; 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(a)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(a)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. >> > >

Hi, On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com > wrote: > > >> 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. > Nope, I spec'ed this such that securityContext.getCallerPrincipal() MUST return the *exact* principal type that was set by the authentication mechanism.

If the code in the (user provided) authentication mechanism sets a MyPrincipal, then a MyPrincipal, and only a MyPrincipal must be returned. I'm going to push for a TCK test to be added for this (although I can't guarantee that as it's outside my influence, unfortunately). > > >> @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 :) > Perhaps an exception could be thrown if not unwrappable, or an Optional could be returned that would be empty if not unwrappable, etc.

Kind regards, Arjan Tijms > 2017-04-26 17:11 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com&gt;: >>> >>>> 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(a)spartasystems.com&gt; 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(a)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(a)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. >>>> >>> >>> >> >