[cdi-dev] Types of Principal object

[Romain Manni-Bucau]

2017-04-26 18:18 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

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

Yep and my statement is still true. You can still wrap the context in a
filter and break that so a user can't rely on it.


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

Think in the related ticket point is exposing a method which would fail
often is too risky


>
> 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/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/245a90ba/attachment-0001.html