Re: [cdi-dev] Types of Principal object

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