<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;">Hi,</div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;">Thanks for your answer.</div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"> </div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;">So I have edited my "services.xml" in order to enable the attribute registry, then I switched to the "attribute-resolver.xml" version without any transcoding configuration.</div>
<div style="font-family: arial, helvetica,sans-serif; font-size: 10pt; color: #000000;"> </div>
<div>It is now much better, I get SAML assertions according to the provided switch.</div>
<div> </div>
<div>Regards<br /><br />Le 29-Sep-2022 17:13:21 +0200, users@shibboleth.net a écrit:</div>
<blockquote style="margin-left: 0; padding-left: 5px; border-left: 2px solid navy;">* spf via users <<a href="mailto:users@shibboleth.net" target="_blank" rel="noreferrer noopener">users@shibboleth.net</a>> [2022-09-29 17:03]:<br />> Even if it's not easy to find recent configuration examples, I also found sources suggesting:<br /><br />Some of those are just wrong ("mail" is not a proper attribute name;<br />attribute names should be URIs and MUST be URIs when the nameFormat<br />says they're URIs.)<br /><br />And the differences not only depend on the version of the software<br />used but also what (more modern) features one may have migrated to<br />using, here specifically the (optional) Attribute Registry, which is<br />what allows to remove any Attribute Encoder elements from your<br />Attribute Definitions -- IFF your system is properly prepared for<br />that. Which yours won't be after upgrading from v3 -- which is fine.<br /><br />> When I checked with "aacli", I get a different output from IDP3 and IDP4. IDP3_LEGACY: {<br />> "name": "mail",<br />> "values": [<br />> "StringAttributeValue{value=<a href="mailto:test.user@my.domai" target="_blank" rel="noreferrer noopener">test.user@my.domai</a>n}" ]<br />> }, IDP_3.4.9 (with any of the last two syntaxes): {<br />> "name": "mail",<br />> "values": [<br />> "StringAttributeValue{value=<a href="mailto:test.user@my.domai" target="_blank" rel="noreferrer noopener">test.user@my.domai</a>n}" ]<br />> }, IDP4 (with any of the last two syntaxes) : {<br />> "name": "mail",<br />> "values": [<br />> "<a href="mailto:test.user@my.domai" target="_blank" rel="noreferrer noopener">test.user@my.domai</a>n"<br />> ]<br />> },<br /><br />FWIW, if you only have to care about or are interested in the actual<br />SAML wire representation you'd use the aacli with the --saml2 option.<br /><br />> Do I take a risk if I choose the less verbose syntax (without any<br />> AttributeEncoder)<br /><br />You don't take that risk. Migrating to the new Attribute Registry is<br />something you can do later (if ever), once the software has been<br />upgraded and everything continues to work without any SPs noticing any<br />changes.<br /><br />-peter<br />-- <br />For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" target="_blank" rel="noreferrer noopener">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br />To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank" rel="noreferrer noopener">users-unsubscribe@shibboleth.net</a></blockquote>
<br/><hr>FreeMail powered by <a href="https://mail.fr" target="_blank">mail.fr</a>