IdP v3 not releasing attributes to SAML1 SPs

[Cantor, Scott]

> > There's absolutely no difference in SAML 1 behavior. Attributes are
> > omitted unless you tell it to push them, same as before.
> 
> Just to be sure you keep the right perspective, I'm just clueless, not
> being arguementative!  And, to prove it...  "Same as before?"  What did I
> do before to push them?

I don't know, and would seriously doubt, that you did push them or it wouldn't be broken now.

If you can't fix the back channel and you don't care about the sensitivity of the data you're sending, and you want a quick fix for most of the broken services, you can set the includeAttributeStatement profile flag in the profile configuration for SAML 1 (Shibboleth) SSO.

> So, if it's all identical, just the same, then why would you need to make
> this change?

I didn't need to; I wanted to get rid of the back channel, and I only had a small number of SPs left, so I just dumped it and switched the behavior when I upgraded.

> What does it take to deliberately turn off SAML1 queries?

Pushing attributes, disabling the query profile, not offering a second port, and changing my metadata.

> Would I simply stop advertising an ArtifactResolutionService endpoint for a SAML1 SOAP
> binding in my metadata?

I didn't say anything about artifact support. I never supported artifacts, so that wasn't a change for me. I'm talking about queries. Queries are not artifact resolution requests. They're both SOAP.
 
> Or, is there more to it than that?  Is there some
> IdP config file that also needs changed?

Changing the metadata is the first thing to do once you're done supporting something, and turning off the profile in the IdP would be last.

--Scott