[keycloak-user] SAML Token contains carriage returns (&#xD)

John Dennis jdennis at redhat.com
Tue Oct 16 12:03:56 EDT 2018


The original poster was seeing unexpected carriage returns in the SAML 
message emitted by Keycloak. I just discovered another issue where 
Keycloak inserts line feeds in HTTP-Redirect messages in violation of 
the SAML spec causing some SAML implementations to fail to process the 
message. I filed this JIRA to cover the case:

https://issues.jboss.org/browse/KEYCLOAK-8594

On 10/3/18 3:45 AM, Hynek Mlnarik wrote:
> Keycloak usually does not add any carriage return entities. What version of
> keycloak do you use? Have you changed/endorsed any XML processing library?

What I find interesting in the XML Dean shared below is the carriage 
returns are not uniformly appearing at each line ending as one might 
expect. Rather they only appear in the signature digest and 
X509Certificate values. My guess is these values are being inserted as 
strings into string data and those particular string values have Windows 
line-endings.

However the carriage returns should not cause the XML parser to fail, 
see this part of the XML spec:

https://www.w3.org/TR/REC-xml/#sec-line-ends

>     2.11 End-of-Line Handling
> 
>     XML parsed entities are often stored in computer files which, for
>     editing convenience, are organized into lines. These lines are
>     typically separated by some combination of the characters CARRIAGE
>     RETURN (#xD) and LINE FEED (#xA).
> 
>     To simplify the tasks of applications, the XML processor must
>     behave as if it normalized all line breaks in external parsed
>     entities (including the document entity) on input, before parsing,
>     by translating both the two-character sequence #xD #xA and any #xD
>     that is not followed by #xA to a single #xA character.

What is also interesting is the values with carriage returns in them are 
base64 data. So Websphere might be having a similar problem as in the 
above JIRA where is aborts after seeing a character not in the base64 
alphabet. However this is quite different than the JIRA reported above, 
read on...

Also note the SAML Core spec says this:

>     Applications that compare data received in SAML documents to data
>     from external sources MUST take into account the normalization
>     rules specified for XML. Text contained within elements is
>     normalized so that line endings are represented using linefeed
>     characters (ASCII code 10 Decimal ), as described in the XML
>     Recommendation [XML] Section 2.11.

And furthermore the XML Signature Specification reiterates the above 
with this requirement

>     1. line endings are normalized to the single character #xA by
>     dropping #xD characters if they are immediately followed by a #xA
>     and replacing them with #xA in all other cases,


As for the Digest and X509Certificate elements (as well as anything else 
contained in XML Signature elments the XML Signature spec does not place 
restrictions on line endings other than noted above. With respect to 
base64 encoded data in XML signature elements the only requirement is 
the base64 text comply with RFC 2045 which not only permits line endings 
but requires wrapping at 76 characters *and* states any character not in 
the base64 alphabet is to be ignored.

Therefore my conclusion is that if WebSphere is unable to process the 
XML document with the carriage returns it is not spec compliant. Note 
this is very different that the JIRA filed above with respect to 
whitespace in base64 data because the SAML binding spec *requires* the 
base64 text to omit whitespace (a deviation from RFC 2045).



> On Mon, Sep 17, 2018 at 6:31 PM Dean Peterson <peterson.dean at gmail.com>
> wrote:
> 
>> Is there a way to remove the carriage returns keycloak uses in the saml
>> assertion token? This is incompatible with Websphere idAssertion using
>> keycloak as the Identity provider. Ex, notice the &#xD characters in the
>> content:
>>
>> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>> xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
>> ID="ID_a42073de-3815-4951-8db4-5d07d46dbf75"
>> IssueInstant="2018-09-17T05:35:29.198Z" Version="2.0"><saml:Issuer>
>> http://localhost:8080/auth/realms/unemployment-insurance
>> </saml:Issuer><dsig:Signature
>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#
>> "><dsig:SignedInfo><dsig:CanonicalizationMethod
>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#
>> "></dsig:CanonicalizationMethod><dsig:SignatureMethod
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
>> "></dsig:SignatureMethod><dsig:Reference
>>
>> URI="#ID_a42073de-3815-4951-8db4-5d07d46dbf75"><dsig:Transforms><dsig:Transform
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature
>> "></dsig:Transform><dsig:Transform
>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#
>> "></dsig:Transform></dsig:Transforms><dsig:DigestMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256
>>
>> "></dsig:DigestMethod><dsig:DigestValue>8aoA9CDfFV8PXBnuafSS3JU/MXuGX3to93E+go9DJrk=</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>UpQPIpNTXMuds8BP5a/N08sXeVMV9Bo6/gxb+rZo38tJwu9GGdrX2SeUlQUWVKRcH0qQRlWzVLfO&#xD;
>>
>> nvb9gbIs/qGrIRQf2nvb40ywN0V8QqCaQr8VU++2rOJGSUfByGjazopvp2WrOM0JdlD6WjeqCs27&#xD;
>>
>> L+fpbVKC8GGZQB+KblqQ08xJ17yN0VDxwDAk+QDwkGpioe9p6/nSZZYCIimPF8BR0TxgwCm9KZl7&#xD;
>>
>> ASNv+d7m6Zaarj/CnqjLG0zDWPfAdW6R5sWuRmUzHiDG3AwpOaxxLP2d5HGPCRCfmiCHMVN3EVx4&#xD;
>>
>> FoQg/ej8QQ1Z0fCOg/N9qRJnFxYbnjMdc1w4rw==</dsig:SignatureValue><dsig:KeyInfo><dsig:KeyName>Ayvm2xqFD1Xb_CeLG0LbFdh2PuBAflqKnI7kCiTwqjw</dsig:KeyName><dsig:X509Data><dsig:X509Certificate>MIICuzCCAaMCBgFlsHW+ezANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDDBZVbmVtcGxveW1lbnQg&#xD;
>>
>> SW5zdXJhbmNlMB4XDTE4MDkwNjE5NTUzMVoXDTI4MDkwNjE5NTcxMVowITEfMB0GA1UEAwwWVW5l&#xD;.....
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 


-- 
John Dennis


More information about the keycloak-user mailing list