<div dir="ltr">Problem solved ! Thanks for the help.<div><br></div><div>There was a missing "/" in the entity ID of the SP in production federation metadata while it was correct in the test federation. Consequence : The IDP used the entry in the test federation.</div>
<div><br></div><div style>From what I understood, they also have a tool that creates an attribute filter for each SP based on the origin of its metadata. The filter policy refuses to push attributes to SPs not belonging to the production federation.</div>
<div style><br></div><div style>This explains why we had an authentication but no attributes.</div><div style><br></div><div style>Thanks again,</div><div style><br></div><div style>Rayene,</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Feb 4, 2013 at 1:47 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-04 13:10]:<br>
<div class="im">> I have IDP log section showing the problem. The attributes are first<br>
> resolved and then filtered and deleted.<br>
> The log says that the filter policy corresponding to the SP is not active :<br>
><br>
> 10:17:47.653 - DEBUG<br>
> [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122]<br>
> - Evaluating if filter policy <a href="https://portailwifi.ec-nantes.fr/" target="_blank">https://portailwifi.ec-nantes.fr/</a> is active<br>
> for principal <hidden><br>
> 10:17:47.653 - DEBUG<br>
> [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:126]<br>
> - Filter policy <a href="https://portailwifi.ec-nantes.fr/" target="_blank">https://portailwifi.ec-nantes.fr/</a> is not active for<br>
> principal <hidden><br>
<br>
</div>Well, that's your answer then. I don't know what the policy looks like<br>
and I cannot know how or why it does not behave as you expect.<br>
<br>
Maybe someone confused the AttributeFilterPolicy's id with the<br>
entityId of the SP (given that policies seem to have ids like<br>
"<a href="https://portailwifi.ec-nantes.fr/" target="_blank">https://portailwifi.ec-nantes.fr/</a>") or forgot to update one value<br>
after copy&paste. No way for me to know.<br>
<div class="im"><br>
> I suspect that the IDP does not have the right metadata for the<br>
> SP. The SP was in the "renater test federation" few days ago and<br>
> than switched to the "renater production federation". Maybe the IDP<br>
> continues to use the metadata from the test federation (?).<br>
<br>
</div>If there was no metadata for the SP the IDP would have logged that<br>
during an attempt to access the SP (on WARN). If there is metadata and<br>
it's available from multiple sources and the entity descriptors for<br>
the same entityId are identical then it's immaterial where the<br>
metadata came from.<br>
If they do in fact differ (not a good idea to begin with, when they<br>
have the same entityID), well, the current implementation uses the<br>
first one found (i.e., from the first metadata provider configured).<br>
But at this point I don't think this has anything to do with metadata.<br>
<br>
The IdP is not releasing data because it has not been told to do so,<br>
<div class="HOEnZb"><div class="h5">-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>
</div></div></blockquote></div><br></div>