getting desired value into nameID

[Wessel, Keith]

Are you hosting this entity’s metadata yourself? If so, the obvious solution is to pull out the other name ID formats. Then, you won’t have to monkey with relying party overrides. If you aren’t hosting it yourself, I’d ask why not? If it’s not federation metadata, and if I can’t verify a signature on it (which one generally can’t unless it’s coming from someone who really has their act together), I live with the risks of having to manually update it and just download it and put it directly into my local metadata. Then, I can manipulate as needed.
Keith


From: users <users-bounces at shibboleth.net> On Behalf Of IAM David Bantz via users
Sent: Thursday, October 6, 2022 7:26 PM
To: Shib Users <users at shibboleth.net>
Cc: IAM David Bantz <dabantz at alaska.edu>
Subject: Re: getting desired value into nameID

Thank; I do have a relying party override for this and similar entities specifying nameid-format:emailAddress precedence.

In any case every nameid generator in saml-nameid is triggered by SP entityID, and no entityID appears more than once.

David

On 06Oct2022 at 16:10:43, Les LaCroix via users <users at shibboleth.net<mailto:users at shibboleth.net>> wrote:
This sounds a bit like I was seeing the other week.  My problem was a nameIDFormatPrecedence defined in my DefaultRelyingParty bean.  Any format that's in metadata is filtered out if it's not in that list.  The only solution that was suggested in that thread is that a relying party override was needed.

-Les


[https://lh6.googleusercontent.com/QEL1To3Ci_dJA1huaKzfZ0Lf4MaZlAy_f-W3vQjbyzNq_yXq_ZYGv3tuT4dkaZS_bZ5X6fZR4iKzBboZhxbCF5htZFnLNKGqmrzHsVJtsjsy0pfK5w2z0Dlq-EtZcWhv0PxBpWmR]<https://urldefense.com/v3/__http:/www.carleton.edu/__;!!DZ3fjg!6XF-aQZLcGceR0G7BiGYtmjatwEUyLED8rrlKPMyD366bglzZTpaLIeyTC4xQx1WecgKUmd5V036U9SZtHuL$>

Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455


On Thu, Oct 6, 2022 at 7:02 PM IAM David Bantz via users <users at shibboleth.net<mailto:users at shibboleth.net>> wrote:
Yes I’ve run these 3 variations:

  *   all 4 policies
  *   no policies
  *   only the emalAddress policy

On 06Oct2022 at 15:58:52, "Mak, Steven" <makst at upenn.edu<mailto:makst at upenn.edu>> wrote:
For an easy test, remove the other NameIDPolicies in the SP metadata so only emailAddress is remaining.

Then just make sure the logic of your resolver config allows the release of some attribute that can fulfill that policy to that service.

- Steve

From: IAM David Bantz <dabantz at alaska.edu<mailto:dabantz at alaska.edu>>
Date: Thursday, October 6, 2022 at 7:55 PM
To: Mak, Steven <makst at upenn.edu<mailto:makst at upenn.edu>>
Cc: Shib Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Re: getting desired value into nameID
I’m debugging the config against the resolver exerciser and unsolicited request, so no normal incoming SAML request.

David

On 06Oct2022 at 15:42:58, "Mak, Steven" <makst at upenn.edu<mailto:makst at upenn.edu>> wrote:
Double check the SAML request that is coming in. If it is stating something like NameIDPolicy > unspecified + Exact, then that may be why you are having trouble.

- Steve Mak

--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!6XF-aQZLcGceR0G7BiGYtmjatwEUyLED8rrlKPMyD366bglzZTpaLIeyTC4xQx1WecgKUmd5V036UwxR-Hlm$>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
--
For Consortium Member technical support, see https://shibboleth.atlassian.net/wiki/x/ZYEpPw<https://urldefense.com/v3/__https:/shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!6XF-aQZLcGceR0G7BiGYtmjatwEUyLED8rrlKPMyD366bglzZTpaLIeyTC4xQx1WecgKUmd5V036UwxR-Hlm$>
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20221007/9252cbb2/attachment.htm>