idpv3 vs. spring security saml and encodeType="false"

[Cantor, Scott]

On 5/20/15, 9:41 AM, "Jarno Huuskonen" <jarno.huuskonen at uef.fi> wrote:


>
>When we had encodeType="false" in attribute-resolver (idpv3), then
>logins to these spring security saml SPs failed: idp showed successful
>login and attributes released (confirmed with firefox+saml tracer) but
>SP didn't allow user to continue.

I was fairly conservative when I made that change. My preference was to 
just default it, but I decided there were probably buggy SPs around so I 
put the flag in the default files, but I left the property itself 
defaulting to true and of course legacy configs will behave the same as 
before.

>Is anybody else able to confirm/deny if encodeType="false" can cause
>interoperability problems with spring security saml ?

Unless they're claiming to strictly intepret the X.500/LDAP Attribute 
Profile (which we have never explicitly followed other than to drive 
attribute naming), that's more of a bug than anything else. That profile 
would actually require sending a special Encoding attribute too, so by not 
sending it, we're not signalling any intent to follow up.

But this is useful to know, thanks. I would suggest adding it to a page in 
the CommercialInterop wiki section (no, not commercial, but it's the best 
spot we have to track interop bugs).

-- Scott