<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Peter,
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class=""> I guess we would havenoticed decades ago. ;)</blockquote>
<div>That's what I thought too.</div>
<div><br class="">
</div>
<div>Unfortunately, we don't have control of IdP. It is a third party service: <a href="https://support.arlo.co/hc/en-gb/articles/360037740232-Single-sign-on-SSO-and-SAML" class="">https://support.arlo.co/hc/en-gb/articles/360037740232-Single-sign-on-SSO-and-SAML</a></div>
<div><br class="">
</div>
<div>I have the SP debug turned on and decrypted SAML looks fine including the UTF-8 character in the console. If you search "Lee" in the log (<a href="https://pastebin.com/Vx5jf6Py" class="">https://pastebin.com/Vx5jf6Py</a>), you can see it does include the
character. However, when the attribute is passed to mod_shib, it choked. The error log I included in my previous email was from apache.</div>
<div><br class="">
</div>
<div>I'm wondering if it is has something to do with apache config or runtime? Or even mod_shib compile environment?</div>
<div><br class="">
</div>
<div>Cheers,</div>
<div>Pan</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 26 Jun 2021, at 04:20, Peter Schober <<a href="mailto:peter.schober@univie.ac.at" class="">peter.schober@univie.ac.at</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">[CAUTION: Non-UBC Email]<br class="">
<br class="">
* Luo, Pan <<a href="mailto:pan.luo@ubc.ca" class="">pan.luo@ubc.ca</a>> [2021-06-26 02:39]:<br class="">
<blockquote type="cite" class="">We have a user whose name includes an UTF8 character (O’Brien). The<br class="">
character "’" chokes mod_shib when parsing the attribute.<br class="">
</blockquote>
<br class="">
It's not that general of a problem -- if the SP wouldn't support UTF-8<br class="">
(which is also what the standard mandates, IIRC) I guess we would have<br class="">
noticed decades ago. ;)<br class="">
FWIW, I have not had any such problems including when testing with<br class="">
names like "ρεťẹя ŜçҺởьəŗ" (generated by Dick Visser's great -- but<br class="">
now seemingly defunct -- "UTF-8 Generator"[1]). The SP processes these<br class="">
just fine.<br class="">
<br class="">
"We have a user" suggests you also control the IDP -- what's the IDP<br class="">
implementaction? Can you turn up the SP's logging to include the<br class="">
decrypted SAML assertion? Can you disable encryption for this SP at<br class="">
the IDP and check the SAML during transit in the browser (using<br class="">
SAMLTracer)? Does the problem occur at all your SPs or only this one?<br class="">
<br class="">
-peter<br class="">
<br class="">
[1] <a href="https://www.tienhuis.nl/utf8-generator" class="">https://www.tienhuis.nl/utf8-generator</a><br class="">
-- <br class="">
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" class="">
https://wiki.shibboleth.net/confluence/x/coFAAg</a><br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>