Problems extracting attributes

Rayene Ben Rayana rayene.benrayana at
Mon Feb 4 09:32:06 EST 2013

Problem solved ! Thanks for the help.

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.

>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

This explains why we had an authentication but no attributes.

Thanks again,


On Mon, Feb 4, 2013 at 1:47 PM, Peter Schober <peter.schober at>wrote:

> * Rayene Ben Rayana <rayene.benrayana at> [2013-02-04 13:10]:
> > I have IDP log section showing the problem. The attributes are first
> > resolved and then filtered and deleted.
> > The log says that the filter policy corresponding to the SP is not
> active :
> >
> > 10:17:47.653 - DEBUG
> >
> [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122]
> > - Evaluating if filter policy is
> active
> > for principal <hidden>
> > 10:17:47.653 - DEBUG
> >
> [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:126]
> > - Filter policy is not active for
> > principal <hidden>
> Well, that's your answer then. I don't know what the policy looks like
> and I cannot know how or why it does not behave as you expect.
> Maybe someone confused the AttributeFilterPolicy's id with the
> entityId of the SP (given that policies seem to have ids like
> "") or forgot to update one value
> after copy&paste. No way for me to know.
> > 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 (?).
> If there was no metadata for the SP the IDP would have logged that
> during an attempt to access the SP (on WARN). If there is metadata and
> it's available from multiple sources and the entity descriptors for
> the same entityId are identical then it's immaterial where the
> metadata came from.
> If they do in fact differ (not a good idea to begin with, when they
> have the same entityID), well, the current implementation uses the
> first one found (i.e., from the first metadata provider configured).
> But at this point I don't think this has anything to do with metadata.
> The IdP is not releasing data because it has not been told to do so,
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the users mailing list