nameID format error

[IAM David Bantz]

*Oh me ridiculum*! Configuring in saml-nameid.xml was the answer all along
exactly as I was being told here. I was distracted by my old relying party
configs; removed misguided attempt to configure there and added a proper
generator and activation condition in saml-nameid.xml which worked first
try.

Thank you,

David Bantz


On Mon, Sep 11, 2017 at 5:29 PM, Klingenstein, Nate <
nklingenstein at calstate.edu> wrote:

> 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> wrote:
>
>> On 9/11/17, 7:34 PM, "users on behalf of Klingenstein, Nate" <
>> users-bounces at shibboleth.net on behalf of 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
>>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170911/8947a9bc/attachment-0001.html>