SAML2 AttributeService endpoints

[Cantor, Scott]

On 3/31/14, 7:15 AM, "Tom Scavo" <trscavo at gmail.com> wrote:
>
>A situation something like the following: An IdP intentionally will
>not release attributes to an SP for policy reasons. No attributes
>arrive on the front channel (even though that's the IdP's usual mode
>of operation) so the SP blindly attempts to query for attributes. Now
>suppose the query fails for some other reason (e.g., misconfigured
>certificate on the IdP end, network issue, unable to negotiate TLS
>session, lack of protocol support, etc.). The SP is led to believe
>there's some issue at the IdP (which there is) and some poor admin may
>spend time contacting IdP tech support to resolve the issue only to
>find the IdP doesn't support SAML2 attribute query at all. <duh> The
>problem was (and still is) attribute release.

That's exactly the same experience for the user, very much by design,
because the actual problem is "required attributes not received" and
that's all that matters from a user perspectice, since the user can't
diagnose the issue, and since in both cases the cause is the IdP (mostly).
The only approach for an SP is to detect the missing attributes and handle
the error generically.

If an IdP has a workflow to deal with this in the first place, then that
will lead to troubleshooting in the event that somebody believes it's not
a policy choice to have not released the attributes.

I don't see having the endpoints in metadata as causing a user experience
issue, just the extra network traffic.

>You gave me the clueful answer, but I'm looking for clueless answer. I
>usually tell people: if your IdP *always* pushes attributes on the
>front channel, you don't need a SAML2 AttributeService endpoint in
>metadata, and in fact that can lead to unnecessary and even spurious
>errors at the SP. If you don't use it, remove it.

The clueless will have no idea what you mean by that either.

>What in the IdP configuration directs the IdP to push attributes on
>the front channel? How do I configure an IdP to support (or not
>support) SAML2 attribute query.

The includeAttributeStatement setting, but it's defaulted in the expected
ways, so most people won't see it. I guess if you have it turned on for
SAML 1.1, then it's safe to conclude you probably aren't doing anything
with queries, and if you are, you'd know it.

>Seems to me the real problem is SAML1. If I could convince IdP admins
>to stop supporting SAML1, no attribute query support would be needed,
>period.

Yes. My point was that if you don't know your use cases (i.e., that you
support SAML 1.1 with attribute query instead of push, or that you run
some kind of stand-alone attribute service), you can't tell from the
configuration that you do or don't, unless you deliberately have turned
off SAML 1.1, I guess. That isn't the default, and I don't think we feel
able to make it the default.

>> That said, there aren't too many people relying on SAML 2 queries that I
>> can think of.
>
>But how do you know one when you see one?

I guess you check the logs?

-- Scott