<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">>I try to configure an IdP 3.2 so, that the IdPs Attribute Resolver tries to resolve only the requested attributes from the relying party and NOT all attributes from the attribute definitions like now.<br>
<br>
</span>Filtering happens at the end, it is not part of the determination of what to resolve. You would have to code a custom activation condition to attach to the resolver plugins that actually did all the work of looking at the metadata.<span class=""><font color="#888888"><br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">OK, but is there another solution without metadata to determine what is to resolve?  With the AuthnRequest from the SP for example?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think there must be a solution, because I looked into the source code of the IdPs Attribute Resolver implementation. In the AttributeResolutionContext is the following field:</div><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_extra">    /** (internal) Names of the attributes that have been requested to be resolved. */</div><div class="gmail_extra">    @Nonnull @NonnullElements private Set<String> requestedAttributeNames;</div><div class="gmail_extra"><br></div><div class="gmail_extra">And because this set is always empty on my IdP, the AttributeResolverImpl class tries to resolve all attributes.</div><div class="gmail_extra">The question is, from where the IdP should get these attribute names?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Simon</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>