nameID format error

[Klingenstein, Nate]

David,


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.


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.


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.


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.


https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2#UpgradingFromV2-Post-UpgradeTasksforrelying-party.xml


Take care,

Nate.

________________________________
From: users <users-bounces at shibboleth.net> on behalf of IAM David Bantz <dabantz at alaska.edu>
Sent: Monday, September 11, 2017 6:08:15 PM
To: Shib Users
Subject: Re: nameID format error

I have two encoders in the resolver for the eduPersonUniqueID SAML attribute I'm trying to use for nameID:
1) "normal" SAML2ScopedString encoder
2)  SAML2StringNameID encoder for use as subject

Is that trying to be too clever? Do I have to define a new SAML attribute with just the nameID encoding?

David

On Mon, Sep 11, 2017 at 4:30 PM, Cantor, Scott <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>> wrote:
On 9/11/17, 7:34 PM, "users on behalf of Klingenstein, Nate" <users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net> on behalf of nklingenstein at calstate.edu<mailto:nklingenstein at calstate.edu>> wrote:

> 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
> attribute that meets the requirements of the request.

That of course is true but he had a release rule and I assumed that was checked.

> 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-
> nameid.xml for this if it's going to use the actual NameID signaling.

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.

-- Scott


--
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/20170912/a1106421/attachment.html>