I also get the expected corrects characters when i defalte and decode my SamlResponse in Notepad++. I believe it's ok. I have closed my support case as IBM.
Original Message:
Sent: Thu August 01, 2024 03:16 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
I will update in this thread when/if there is a fix.
Yes I have provided this info.
@Carsten Jensen I would create a ticket if I were you. Maybe the fixes they provided me works for you. And maybe it's good that they see that I am not the only one having these issues.
------------------------------
Jonatan Wålegård
Original Message:
Sent: Thu August 01, 2024 01:38 AM
From: Carsten Jensen
Subject: Characters are not being encoded in SAML assertion
Hi Jonatan
It's ok :-)
Thanks for info. I was just about to create a ticket myself, but now it may seem obsolete.
Please update the thread if you, or Shane has any news. Maybe your input about misinterpretation rings a bell at the lab. Have you updated your ticket with this information?
BR Carsten
------------------------------
Carsten Jensen
ATP
+4530595704
Original Message:
Sent: Wed July 31, 2024 07:55 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
@Carsten Jensen Sorry! Not sure why I didn't receive an email about you replying, maybe I did..
I still have my ticket open with IBM about this since November last year. They have provided me a few fixpacks along the way - of which none have provided a solution.
ChatGPT said this about the issue:
What's Happening?
Original Character (UTF-8): The character å (U+00E5) is encoded in UTF-8 as two bytes: C3 A5.
Misinterpretation: When the data is encoded in UTF-8 but interpreted as ISO-8859-1, each byte is treated as an individual ISO-8859-1 character:
C3 in ISO-8859-1 is ÃA5 in ISO-8859-1 is ¥
So the sequence C3 A5 is misinterpreted as å.
------------------------------
Jonatan Wålegård
Original Message:
Sent: Mon July 29, 2024 02:41 AM
From: Carsten Jensen
Subject: Characters are not being encoded in SAML assertion
Hi Shane and Jonatan
Did you reach any conclusion on this issue?
Best regards Carsten
------------------------------
Carsten Jensen
ATP
+4530595704
Original Message:
Sent: Tue May 28, 2024 05:30 AM
From: Carsten Jensen
Subject: Characters are not being encoded in SAML assertion
Hi Shane and Jonatan
Jonatan, did you succeed in getting the proper utf-8 encoded saml response?
You mentioned a ticket. Still no response? Maybe Shane could review this?
(in my case, the PingIdentity SAML decoder still shows "the ugly" format for the certificate subject - and also in the saml:Attribute Name="Fullname" which (the users name) i changed to contain a danish "æ")
Shane, You wrote "Unlikely. Because in my case I had to set that value on a container deployment to FIX my issue with incorrect UTF8 character encoding. "
So the LANG=en_US.utf8 have no effect in Jonatan's and my issue.
Regards Carsten
------------------------------
Carsten Jensen
ATP
+4530595704
Original Message:
Sent: Thu May 23, 2024 12:58 AM
From: Carsten Jensen
Subject: Characters are not being encoded in SAML assertion
Hi Shane
Thank you for your reply.
The LANG environment variable, it's the same value as Jonatan's, LANG=en_US.utf8
I'm not sure if Jonatan reached any conclusion?
BR Carsten
------------------------------
Carsten Jensen
ATP
+4530595704
Original Message:
Sent: Wed May 22, 2024 08:29 AM
From: Shane Weeden
Subject: Characters are not being encoded in SAML assertion
Did you verify the setting of your LANG environment variable (in a mapping rule for example)? That has almost always been the answer in the past.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Wed May 22, 2024 02:21 AM
From: Carsten Jensen
Subject: Characters are not being encoded in SAML assertion
Hi Jonatan, Shane and more.
Did you reach a conclusion?
I have problems with Danish national characters in the certificate subject:
In an Idp we use a personal certificate where the subject contains a Danish national character. "æ".
It displays fine in certificate viewer i.e. https://www.sslshopper.com/certificate-decoder.html and "Crypto Shell Extention" in Windows.
According to certutil it it UTF8 encoded
$ certutil -asn atp_kup_idp_test.cer
0000: 30 82 03 8f ; SEQUENCE (38f Bytes)
0004: 30 82 02 77 ; SEQUENCE (277 Bytes)
0008: | 02 04 ; INTEGER (4 Bytes)
000a: | | 56 67 e2 0f
000e: | 30 0d ; SEQUENCE (d Bytes)
0010: | | 06 09 ; OBJECT_ID (9 Bytes)
0012: | | | 2a 86 48 86 f7 0d 01 01 05
| | | ; 1.2.840.113549.1.1.5 sha1RSA
001b: | | 05 00 ; NULL (0 Bytes)
001d: | 30 81 8b ; SEQUENCE (8b Bytes)
0020: | | 31 0b ; SET (b Bytes)
0022: | | | 30 09 ; SEQUENCE (9 Bytes)
0024: | | | 06 03 ; OBJECT_ID (3 Bytes)
0026: | | | | 55 04 06
| | | | ; 2.5.4.6 Land/omr▒de (C)
0029: | | | 13 02 ; PRINTABLE_STRING (2 Bytes)
002b: | | | 44 4b ; DK
| | | ; "DK"
002d: | | 31 39 ; SET (39 Bytes)
002f: | | | 30 37 ; SEQUENCE (37 Bytes)
0031: | | | 06 03 ; OBJECT_ID (3 Bytes)
0033: | | | | 55 04 0a
| | | | ; 2.5.4.10 Organisation (O)
0036: | | | 0c 30 ; UTF8_STRING (30 Bytes)
0038: | | | 41 72 62 65 6a 64 73 6d 61 72 6b 65 64 65 74 73 ; Arbejdsmarkedets
0048: | | | 20 54 69 6c 6c c3 a6 67 73 70 65 6e 73 69 6f 6e ; Till..gspension
0058: | | | 20 2f 2f 20 43 56 52 3a 34 33 34 30 35 38 31 30 ; // CVR:43405810
| | | ; "Arbejdsmarkedets Till▒gspension // CVR:43405810"
0068: | | 31 41 ; SET (41 Bytes)
006a: | | 30 3f ; SEQUENCE (3f Bytes)
006c: | | 06 03 ; OBJECT_ID (3 Bytes)
006e: | | | 55 04 03
| | | ; 2.5.4.3 Almindeligt navn (CN)
0071: | | 0c 38 ; UTF8_STRING (38 Bytes)
0073: | | 41 72 62 65 6a 64 73 6d 61 72 6b 65 64 65 74 73 ; Arbejdsmarkedets
0083: | | 20 54 69 6c 6c c3 a6 67 73 70 65 6e 73 69 6f 6e ; Till..gspension
0093: | | 20 2d 20 41 54 50 20 4b 55 50 20 49 64 50 20 54 ; - ATP KUP IdP T
00a3: | | 65 73 74 2f 50 69 6c 6f ; est/Pilo
| | ; "Arbejdsmarkedets Till▒gspension - ATP KUP IdP Test/Pilo"
But in a SamlResponse from the IdP it is converted to "æ", not nice. Is there any way to solve this?
BR, Carsten
------------------------------
Carsten Jensen
ATP
+4530595704
Original Message:
Sent: Fri March 01, 2024 08:34 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
I'm a little bit confused at the moment, because:
SAML Addon in Chrome shows:
<saml:AttributeValue xsi:type="xs:string">Wålegård</saml:AttributeValue>
Trace from ISVA SP shows (fetching the actual attribute from the STSUU):
traceString ENTRY surname is what from preldap: Wålegård
But when I take the very same SAML response and decode it at https://developer.pingidentity.com/en/tools/saml-decoder.html, I get:
<saml:AttributeValue xsi:type="xs:string">Wålegård</saml:AttributeValue>
------------------------------
Jonatan Wålegård
Original Message:
Sent: Fri March 01, 2024 08:15 AM
From: Shane Weeden
Subject: Characters are not being encoded in SAML assertion
Unlikely. Because in my case I had to set that value on a container deployment to FIX my issue with incorrect UTF8 character encoding.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Fri March 01, 2024 07:54 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
It worked.
The variable is set to:
LANG=en_US.utf8
Is this causing the issue?
------------------------------
Jonatan Wålegård
Original Message:
Sent: Fri March 01, 2024 07:43 AM
From: Shane Weeden
Subject: Characters are not being encoded in SAML assertion
Actually LANG=C may not be the best choice - I checked and one of my runtime containers in a demo env where I was testing a similar (not identical) issue was remediated by this YAML entry for the container deployment:
- name: LANG
value: "en_US.utf8"
In a mapping rule, try something like (I haven't tested this, it's late, working from top of my head...):
IDMappingExtUtils.traceString(java.lang.System.getenv())
At least try to get some visibility into what the current LANG setting is, and whether or not that is a factor.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Fri March 01, 2024 07:35 AM
From: Shane Weeden
Subject: Characters are not being encoded in SAML assertion
Containers or appliance? In containers it's dependent on your container runtime, such as in the kubernetes deployment yaml. In appliance it should already be set but I don't recall whether that's really true for 10.0.4 or not since that's fairly old now. I would suggest you add trace to dump all environment variables in your SAML mapping rule first to see what is actually set.
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Fri March 01, 2024 07:25 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
@Shane Weeden Thanks for the tip. Where do I actually set that variable?
------------------------------
Jonatan Wålegård
Original Message:
Sent: Fri March 01, 2024 01:54 AM
From: Shane Weeden
Subject: Characters are not being encoded in SAML assertion
Try setting the LANG=C env var for the AAC runtime
------------------------------
Shane Weeden
IBM
Original Message:
Sent: Thu February 29, 2024 03:15 AM
From: Jonatan Wålegård
Subject: Characters are not being encoded in SAML assertion
Hi,
Nordic characters, e.g. "åäö", are not being encoded correctly from ISVA IDP.
They appear as the following in the SAML response:
årdåäö
This makes the federation break from the SP side (which is also running ISVA).
I've had a ticket open with IBM for 3 months now and they haven't been able to pinpoint where the issue even is.
Any ideas?
IDP is running 10.0.4
------------------------------
Jonatan Wålegård
------------------------------