<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2017-04-26 18:18 GMT+02:00 arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Apr 26, 2017 at 6:10 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><div class="m_6765061379480428475gmail-m_9066853587441782408gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div></div></div></div>
<div class="gmail_quote"><span class="m_6765061379480428475gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Security context:</div><div><br></div><div>@Inject SecurityContext securityContext;<br></div><div><br></div><div>...</div><div><br></div><div>MyPrincipal myPrincipal = securityContext.getCallerPrinc<wbr>ipal();<br></div><div><br></div><div>Spot the differences ;)</div></div></div></div></blockquote><div><br></div></span><div>Here you can get a PrincipalFacade which limits MyPrincipal to getName() only, this is perfectly valid per spec.</div></div></div></div></blockquote><div><br></div></span><div>Nope, I spec'ed this such that securityContext.getCallerPrinc<wbr>ipal() MUST return the *exact* principal type that was set by the authentication mechanism.</div></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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).</div><span class=""><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_6765061379480428475gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_6765061379480428475gmail-m_9066853587441782408gmail-"><div>@Inject CallerPrincipal callerPrincipal;<br></div></span><div>@Inject BeanManager beanManager;</div><div><br></div><div>...</div><div><br></div><div>MyPrincipal myPrincipal = beanManager.unwrap(callerPrinc<wbr>ipal);</div></div></div></div></blockquote><div><br></div></span><div>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 :)</div></div></div></div></blockquote><div><br></div></span><div>Perhaps an exception could be thrown if not unwrappable, or an Optional could be returned that would be empty if not unwrappable, etc.</div></div></div></div></blockquote><div><br></div><div>Think in the related ticket point is exposing a method which would fail often is too risky</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_6765061379480428475gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_6765061379480428475gmail-m_9066853587441782408gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><span class="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-"></span><div><div class="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-h5"><div class="gmail_quote">2017-04-26 17:11 GMT+02:00 arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><div>public abstract class AbstractEEBean<T> extends AbstractStaticallyDecorableBui<wbr>ltInBean<T> {</div><div><br></div><div> private final T proxy;</div><div><br></div><div> protected AbstractEEBean(Class<T> type, Callable<T> callable, BeanManagerImpl beanManager) {</div><div> super(beanManager, type);</div><div> this.proxy = new ProxyFactory<T>(beanManager.ge<wbr>tContextId(), type, getTypes(), this).create(new EnterpriseTargetBeanInstance(t<wbr>ype, new CallableMethodHandler(callable<wbr>)));</div><div> }</div></div><div> // ...</div><div>}</div><div><br></div><div>I'm not even sure if it's possible to downcast the proxy to the required runtime type.</div><div><br></div><div>Also note that the Principal can change during the request. The simplest case is when during an http request HttpServletRequest#logout is called.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-m_-5104628441580598949h5">On Wed, Apr 26, 2017 at 3:54 PM, John Ament <span dir="ltr"><<a href="mailto:john.ament@spartasystems.com" target="_blank">john.ament@spartasystems.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-m_-5104628441580598949h5">
<div dir="ltr">
<div id="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-m_-5104628441580598949m_-6220285763532774275m_-7940682118025092754divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:calibri,arial,helvetica,sans-serif" dir="ltr">
<p>Hey guys</p>
<p><br>
</p>
<p>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?</p>
<p><br>
</p>
<p>John</p>
<div id="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-m_-5104628441580598949m_-6220285763532774275m_-7940682118025092754Signature">
<div id="m_6765061379480428475gmail-m_9066853587441782408gmail-m_5628035824805595007gmail-m_-5104628441580598949m_-6220285763532774275m_-7940682118025092754divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:calibri,arial,helvetica,sans-serif">
<p></p>
</div>
</div>
</div>
<hr>
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.
</div>
<br></div></div><span>______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>