Fail on resolved RequestedAttribute isRequired=true

[Stefan Santesson]

Tom and Eric,

This is actually quite straight forward.
The DS is a service to the SP:s and we have a test federation where they
will try out their metadata configuration to see the effects of the
filtering.
Here they can tweak their metadata until it renders the appropriate set of
IdP:s.
If they don¹t, then it is their problem.

To support this we have defined a set or EntityCategory attributes of
different types. That is all we use in the algorithms today.

What we don¹t know, is what challenges may arise in the future with
regards to demands for filtering capabilities in the DS.
So we are looking out for whatever we can add to the toolbox, if needed,
to meet the requirements of the SP:s

The IdP:s MUST follow the rules of the federation, when it comes to
correctly advertise their capabilities in metadata. They have an economic
incentive. If they fail to do this, they will be filtered out in the DS
and will not earn the money that is paid out for authenticaiton and their
customers will suffer. So its bad business for them not to not comply. If
they advertise capabilities they do not have, they risk getting kicked out
of the federation.

/Stefan

On 16/07/15 02:17, "users on behalf of Eric Goodman"
<users-bounces at shibboleth.net on behalf of Eric.Goodman at ucop.edu> wrote:

>I'd point back to Scott's comment about this seeming to be something more
>likely to be accomplished with entity attributes, rather than required
>attributes. The challenge (that I keep trying but don't have a solution
>for) is that you can only get those entity attributes added if you have
>leverage over the IdPs and SPs so you can entice/require/persuade them to
>add the appropriate entity attributes. If you don't, then you're left
>managing the information locally.
>
>In a recent thread Scott and Jeffrey Crawford talked about a
>"post-download" metadata filter that lets you script the addition of
>entity attributes to your local copies of the metadata; you could
>potentially use that to mark up IdPs and SPs as needed to let the DS
>filter them. Note though, that the filter script would still need to be
>generated and maintained in some way, and it's not obvious that you'll
>have the metadata to automate that generation/maintenance, at least for
>entities outside of your direct scope of control.
>
>--- Eric
>
>-----Original Message-----
>From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Tom Scavo
>Sent: Wednesday, July 15, 2015 6:40 AM
>To: Shib Users
>Subject: Re: Fail on resolved RequestedAttribute isRequired=true
>
>On Wed, Jul 15, 2015 at 4:02 AM, Stefan Santesson <stefan at aaa-sec.com>
>wrote:
>>
>> In our government federation we offer a centralised DS.
>> The goal of this DS is to never show an IdP that is known not to work
>> with the requesting SP.
>
>This is a laudable goal.
>
>> The DS will have a well defined set of algorithms for filtering IdP:s.
>
>I would like to study those algorithms.
>
>> This allows SP:s to configure their metadata so only relevant IdP:s
>> will show up in the DS.
>
>The metadata an SP consumes and the IdPs exposed on its discovery
>interface are two completely different things. So I'm missing an
>important detail: How do the DS and the SP coordinate to filter the same
>set of IdPs?
>
>Thanks,
>
>Tom
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net