<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>David,</p>
<p><br>
</p>
<p>It's not too clever by half. It's just too deprecated by half. It was deprecated in the transition to v3 and it's going to be seriously deprecated(e.g. not even supported anymore) in the transition to v4.</p>
<p><br>
</p>
<p>You'll eventually need to revise your configuration, including for this service, to use the new format. You should do that sooner than later. This is probably the most involved and perilous step for anyone transitioning a large existing deployment, but
if this isn't working, you're probably using the non-legacy parser today anyhow.</p>
<p><br>
</p>
<p>Until then, you *could* follow the mechanism you described by changing the legacy setting back to true, kinda the inverse of the change to services.properties described here, but I would only do that if left no alternative, and I don't know whether flipping
that back would change any of the other behavior you've got apparently working using the new config.</p>
<p><br>
</p>
<p>But I would expect that none of your legacy NameID definitions would be working or that all of them would be working. Having half of them working would be, well, weird.</p>
<p><br>
</p>
<p><a href="https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-Post-UpgradeTasksforrelying-party.xml" class="OWAAutoLink" id="LPlnk975966" previewremoved="true">https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-Post-UpgradeTasksforrelying-party.xml</a><br>
</p>
<p><br>
</p>
<p>Take care,</p>
<p>Nate.</p>
<p></p>
<p></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of IAM David Bantz <dabantz@alaska.edu><br>
<b>Sent:</b> Monday, September 11, 2017 6:08:15 PM<br>
<b>To:</b> Shib Users<br>
<b>Subject:</b> Re: nameID format error</font>
<div> </div>
</div>
<div>
<div dir="ltr"><font color="#000000" face="arial, helvetica, sans-serif">I have two encoders in the resolver for the eduPersonUniqueID SAML attribute I'm trying to use for nameID: </font>
<div><font color="#000000" face="arial, helvetica, sans-serif">1) "normal" <span style="font-variant-ligatures:no-common-ligatures;font-size:11px">SAML2ScopedString </span>encoder</font></div>
<div><font color="#000000" face="arial, helvetica, sans-serif">2) <span style="font-variant-ligatures:no-common-ligatures;font-size:11px">SAML2StringNameID encoder for use as subject</span></font></div>
<div><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div><font face="arial, helvetica, sans-serif">Is that trying to be too clever? Do I have to define a new SAML attribute with just the nameID encoding?</font></div>
<div><font face="arial, helvetica, sans-serif"><br>
</font></div>
<div><font face="arial, helvetica, sans-serif">David</font></div>
<div class="gmail_extra"><font face="arial, helvetica, sans-serif"><br>
</font>
<div class="gmail_quote"><font face="arial, helvetica, sans-serif">On Mon, Sep 11, 2017 at 4:30 PM, Cantor, Scott
<span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br>
</font>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="arial, helvetica, sans-serif"><span class="">On 9/11/17, 7:34 PM, "users on behalf of Klingenstein, Nate" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of
<a href="mailto:nklingenstein@calstate.edu">nklingenstein@calstate.edu</a>> wrote:<br>
<br>
> I typically get that message when the IdP is trying to generate a NameID, but it's unable to do so because I'm not releasing an<br>
> attribute that meets the requirements of the request.<br>
<br>
</span>That of course is true but he had a release rule and I assumed that was checked.<br>
<span class=""><br>
> Whether you're using actual persistentId's with other SP's, I don't know, but you'll probably need to define something in saml-<br>
> nameid.xml for this if it's going to use the actual NameID signaling.<br>
<br>
</span>The formal selection process works the same whether you're generating them the way it's done now or using the legacy fallback to the resolver and its AttributeEncoders. It's just that the legacy generation is controlled with a property and can be turned
off to prevent accidental use of a deprecated method, and it probably defaults to being "off" on a new install.<br>
</font>
<div class="HOEnZb">
<div class="h5"><font face="arial, helvetica, sans-serif"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">
users-unsubscribe@shibboleth.<wbr>net</a><br>
</font></div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</body>
</html>