Problems extracting attributes

[Rayene Ben Rayana]

Thanks Peter,

Indeed, the IDP is filtering the attributes for this particular SP. We just
don't know why for now.

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 https://portailwifi.ec-nantes.fr/ is active
for principal <hidden>
10:17:47.653 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:126]
- Filter policy https://portailwifi.ec-nantes.fr/ is not active for
principal <hidden>

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":

10:17:47.686 - DEBUG
[edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131]
- Filter policy
https://services-federation.renater.fr/validation/ressourceis active
for principal <hidden>
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>
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>
.....

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 (?).

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.


Thanks

Rayene,



On Fri, Feb 1, 2013 at 1:46 PM, Peter Schober <peter.schober at univie.ac.at>wrote:

> * Rayene Ben Rayana <rayene.benrayana at gmail.com> [2013-02-01 13:18]:
> > The SP is actually working with many other IDPs from the same federation.
> > The IDP has also been tested with other resources from the federation
> with
> > success.
>
> There is no guesswork involved at the IdP: The IdP has the logfiles
> which (at least with the Shibboleth IdP) detail which attribute have
> been released.
>
> > The syslog below shows that
> > 1 / no attributes are pushed during SSO (do you confirm ?)
>
> Yes, the SAML assertion does not contain an attribute statement.
>
> > 2 / the attribute resolution fails... This is because there's no
> > "AttributeAuthorityDescriptor" in the IDP's metadata (see
> > discussion<
> https://lists.internet2.edu/sympa/arc/shibboleth-users/2009-06/msg00040.html
> >
> > ).
>
> Indeed RENATER does not have an AttributeAuthority for this entity.
>
> > Any idea on how to solve this issue ?
>
> Well, the IdP did not send an attribute statement during SSO.
> So they should fix that and start sending one.
>
> If both parties suport SAML2 -- as is obvious from the log -- I
> wouldn't mess with attribute queries. If the IdP is Shibboleth adding
> attribute queries also wouldn't change anything, it still wouldn't
> release anything during a query what it wouldn't have pushed during
> SSO.
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130204/2ca7610b/attachment.html