<div dir="ltr">Thanks Peter,<div><br></div><div style>Indeed, the IDP is filtering the attributes for this particular SP. We just don't know why for now.</div><div style><br></div><div style>I have IDP log section showing the problem. The attributes are first resolved and then filtered and deleted.<br>
</div><div style>The log says that the filter policy corresponding to the SP is not active :<br></div><div style><br></div><div style><div style><span style="font-family:'courier new',monospace">10:17:47.653 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy <a href="https://portailwifi.ec-nantes.fr/">https://portailwifi.ec-nantes.fr/</a> is active for principal <hidden></span><br>
</div><div><font face="courier new, monospace">10:17:47.653 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:126] - Filter policy <a href="https://portailwifi.ec-nantes.fr/">https://portailwifi.ec-nantes.fr/</a> is not active for principal <hidden></font></div>
<div><br></div><div style>We used the same IDP with another (working) SP and the corresponding log section tells that the corresponding filter is active followed by a bunch of "processing permit":</div><div><br>
</div><div><div><span style="font-family:'courier new',monospace">10:17:47.686 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131] - Filter policy <a href="https://services-federation.renater.fr/validation/ressource">https://services-federation.renater.fr/validation/ressource</a> is active for principal <hidden></span><br>
</div><div><font face="courier new, monospace">10:17:47.686 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute supannAutreMail for principal <hidden></font></div>
<div><font face="courier new, monospace">10:17:47.686 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonPrimaryAffiliation for principal <hidden></font></div>
</div><div>.....</div><div><br></div><div style>I suspect that the IDP does not have the right metadata for the SP. The SP was in the "renater test federation" few days ago and than switched to the "renater production federation". Maybe the IDP continues to use the metadata from the test federation (?).<br>
</div><div style><br></div><div style>How can I check that through the log ? The ChainingMetadataProvider log section does not tell me the origin of the metadata used to "identify" the relying party.</div><div>
<br>
</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">Thanks</span><br></div><div><br></div><div style>Rayene,</div></div><div style><br></div></div><div class="gmail_extra">
<br>
<br><div class="gmail_quote">On Fri, Feb 1, 2013 at 1:46 PM, Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Rayene Ben Rayana <<a href="mailto:rayene.benrayana@gmail.com">rayene.benrayana@gmail.com</a>> [2013-02-01 13:18]:<br>
<div class="im">> The SP is actually working with many other IDPs from the same federation.<br>
> The IDP has also been tested with other resources from the federation with<br>
> success.<br>
<br>
</div>There is no guesswork involved at the IdP: The IdP has the logfiles<br>
which (at least with the Shibboleth IdP) detail which attribute have<br>
been released.<br>
<div class="im"><br>
> The syslog below shows that<br>
> 1 / no attributes are pushed during SSO (do you confirm ?)<br>
<br>
</div>Yes, the SAML assertion does not contain an attribute statement.<br>
<div class="im"><br>
> 2 / the attribute resolution fails... This is because there's no<br>
> "AttributeAuthorityDescriptor" in the IDP's metadata (see<br>
</div>> discussion<<a href="https://lists.internet2.edu/sympa/arc/shibboleth-users/2009-06/msg00040.html" target="_blank">https://lists.internet2.edu/sympa/arc/shibboleth-users/2009-06/msg00040.html</a>><br>
> ).<br>
<br>
Indeed RENATER does not have an AttributeAuthority for this entity.<br>
<div class="im"><br>
> Any idea on how to solve this issue ?<br>
<br>
</div>Well, the IdP did not send an attribute statement during SSO.<br>
So they should fix that and start sending one.<br>
<br>
If both parties suport SAML2 -- as is obvious from the log -- I<br>
wouldn't mess with attribute queries. If the IdP is Shibboleth adding<br>
attribute queries also wouldn't change anything, it still wouldn't<br>
release anything during a query what it wouldn't have pushed during<br>
SSO.<br>
-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br></div>