[cdi-dev] Types of Principal object

[arjan tijms]

Hi,

On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau <rmannibucau at 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 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/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/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/e1a96069/attachment.html