Issue with upgrade 3.3 to 4.1 no attributes released

[Cantor, Scott]

>    Well we are using the SAML 2 plugin for CAS as an SP in the InCommon federation to hook into several
> application in CAS, so I would expect there to be some SAML involved. 

I have no idea what what means but CAS as a protocol does not comply with or use any standard SAML features. It misuses SAML syntax in some places optionally but it is in no way using "SAML". It is also a back channel system and all the attribute data gets sent out that channel and not the front channel, so debugging things is completely different in the two cases unless SAML artifacts are being used. The reasons why data wouldn't be present can be very different.

As for your logs...this stuff about the decoding errors has nothing to do with your problem, but the log trace there is missing all of the IdP's own debugging information related to attribute resolution and filtering so you have the logging incomplete.

But my speculation from the fact that the audit log is including attributes in the output but the assertion doesn't is that you've borked the attribute encoding process in some way. It looks as though there are no AttributeEncoders configured in the old legacy way nor are the default transcoding rules used with the Registry service introduced in 4.0 being used. The attributes are there but never get encoded to SAML syntax.

An upgrade done in place could not cause that unless there were no encoders present to start with. A new install could cause that if all the internal attribute IDs used by one's resolver file were not ones that the IdP defaults to recognizing in its registry of rules.

But the filtering is fine or it wouldn't be auditing them, so it's clearly resolving and filtering attributes.

-- Scott