allowPerAttribute=true + all unchecked + 8443 = unintended attribute release

[Tom Scavo]

On Fri, Jan 26, 2018 at 6:17 PM, Takeshi NISHIMURA <takeshi at nii.ac.jp> wrote:
> This is another issue when enabling the back channel on Shibboleth IdP.

The back channel is a SAML issue, not a Shibboleth issue.

> We have experienced odd behavior that resulted in unintended attribute release.

Thank you, Takeshi, for sharing this story. You have identified yet
another reason for deployers to eliminate the back channel on the IdP.

> First of all, we are using perAttributeConsentEnabled (idp.consent.allowPerAttribute=true).
> In this mode, you can of course uncheck (disapprove) all the attributes that the IdP attempts to release. When someone checks no attribute, he/she expects for the IdP to send only authentication assertion without any attribute assertion.

I'm sure you thought of this but an obvious workaround (apart from
eliminating the back channel) is to make sure at least one attribute
is always asserted. I assume your IdP is asserting the SAML2 Transient
Identifier in the NameID. In that case, what persistent identifier
does your IdP assert in the attribute assertion? If that is
eduPersonTargetedID, then you are done since the user isn't really
equipped to manage that attribute, anyway.

Regardless of what persistent identifier is in the attribute assertion
(eduPersonTargetedID, eduPersonPrincipalName, or eduPersonUniqueId),
the answer is the same...don't let the user manage that attribute.
Federated SSO is mostly worthless in the absence of a persistent
identifier.

Btw, the OpenID Connect protocol addresses this issue in multiple ways:

- The OIDC 'sub' claim is a REQUIRED claim
- OIDC has no equivalent for the SAML NameID (which itself eliminates
a whole raft of issues)
- OIDC has no equivalent for the SAML AttributeStatement (since a
claim is a claim)

As a SAML IdP deployer, the best long-range solution is to conform to
OpenID Connect, I think.

> Actual final result of this situation is that Shibboleth SP gets all the attributes which are displayed in the consent page through Attribute Query, as it is the default behavior of Shibboleth SP when it gets no attribute assertion.

That, of course, is out of your control (although I understand that
Shibboleth SP V3 will no longer query by default).

> It is also the default behavior of Shibboleth IdP to send all the attributes in attribute-filter.xml through Attribute Query, regardless of with or without the user's consent.

Scott addressed this issue. It seems you must either eliminate the
back channel or populate the attribute assertion on the front channel.
I would do both.

Tom