Attribute Filters using DefaultRelyingParty

[Jeffrey Crawford]

I'll try the aacli tool and see what it reports, I won't be able to do it
today since this is in production and the system is being used quite
heavily today. I'll have to take one of the instances offline and then
perform the command and see what the results are.

I can't imagine this would be important but our IdP has two entity ID's one
is for non inCommon relying parties where we have the IdP's metadata
published on a url, and the second is used for inCommon relying parties. We
change the "provider" on RelyingParty entries depending on which case we
are working with on a particular Service Provider. However I'm using the
same provider entry on the DefaultRelyingParty as the urn:mace:incommon
RelyingParty group id.

I'm not able to reproduce this in our test environment but the big
difference there is that we only use a single entityID since it's not in
inCommon.

Jeffrey
C.
---------------------------------------


On Mon, Mar 31, 2014 at 11:03 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> One thing you probably want to do is to debug the filter policy using the
> aacli tool and make sure the policy fires based on setting the requester
> option there.
>
> Once that works, I have no idea how any change to relying-party.xml can
> affect the policies other than by preventing the attributes from
> resolving, so I'd be looking for comparisons between the log in the aacli
> case and the actual SSO case during the attribute resolver step, and what
> gets passed to the filter.
>
> -- Scott
>
>
> --
> 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/20140331/68130174/attachment.html