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

[Jarno Huuskonen]

Hi,

On Wed, May 20, Cantor, Scott wrote:
> 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.

I did some testing with spring security saml sample application
(http://docs.spring.io/spring-security-saml/docs/current/reference/html/chapter-quick-start.html)

spring security 1.0.1RELEASE sample app. shows attributes correctly
with encodeType="false" and encodeType="true".

1.0.0RC2 (with encodeType="false") sample app. shows attributes as:
mail    org.opensaml.xml.schema.impl.XSAnyImpl at 6499e398
eduPersonPrincipalName  org.opensaml.xml.schema.impl.XSAnyImpl at 54e631c5
...
(and with encodeType="true" shows attribute values).

I think this spring security saml commit
https://github.com/spring-projects/spring-security-saml/commit/f05bae425336ed537f50d60b7fc13742d3724300
adds functions that get the attribute string values (even with
encodeType="false").

So I think(guess) the interoperability problem is that the application
tries to use attributevalues something like this:
    <c:forEach var="attribute"
               items="${credential.attributes}">
        <tr>
            <td>
                <c:forEach var="attributeValue"
                           items="${attribute.attributeValues}">
                    <c:catch var ="catchException">
                        <c:out value="${attributeValue.value}"/> 
                    </c:catch>
                    <c:if test="${not empty catchException}">
                        <c:out value="${attributeValue}"/> 
                    </c:if>
                </c:forEach>
            </td>
        </tr>
    </c:forEach>
--> with encodeType="false" this ends up producing values like:
org.opensaml.xml.schema.impl.XSAnyImpl at 6499e398 ...
(what the application probably should use ise the getAttributeAsString*
functions).

> >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).

Do you mean this page:
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCommercialInterop ?

-Jarno

-- 
Jarno Huuskonen