SAML attributes to IdP Attributes

[Cantor, Scott]

On 5/20/13 5:43 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>Case 1:  Expected Oddness
>
>IdP Attribute A encodes to SAML attribute S & T
>IdP Attribute A has the filter associated with it.
>
>Request limit the values on S to be a & b.
>A starts with values a,b,c,d.
>After encoding both S & T only have two values (a&b) , despite T not
>having
>any restrictions applied.
>
>I think we can argue that this is expected;  anyway there is an obvious
>mitigation.  This was all I meant in my previous mail, I am not proposing
>making multiple encodings of the same attribute illegal, just that if
>oddness occurs which you don't like (a) it is expected and (b) you can do
>something about it.

Yes, that's fair. In such a case, it would be very odd for the SP to be
looking at a second encoding of the same data anyway. We may even decide
to build in new logic to the encoding process that allows encodings to be
"targeted" so they're limited to subsets of SPs. Or we just keep forcing
the creation of a second attribute definition with the second encoding.

>Case 2: GIGO

This one is harder for me to map into a real use case. You certainly could
do it, but in practice it seems pretty warped to define multiple internal
attributes that encode to the same SAML attribute. Essentially you
guarantee that creating an appropriate filter rule for the data becomes
twice as much work, or you end up trying to create some kind of weird
implicit filtering by only putting some of the values into the two
attributes up front. It's just...odd and stupid. So I don't think it's
worth worrying a lot about.

>After filtering and encoding we see S with attribute values of
>((a,b),(1,2,3)).  I'm not sure that this is a valid assertion, but I am
>sure
>that in this case this is what should be expected; you should have
>filtered
>B if you cared).

Right, in which case you could have saved the trouble by not creating B to
begin with.

-- Scott