shibboleth.SAML2PersistentGenerator question

[Les LaCroix]

My problem is resolved.  Here's an update, in case anyone runs across this
thread in the future.

We ended up having an SP that broke.  They do not request a persistent
subject nameID in their metadata, but their requested attribute list
includes ePTID and no other identifier.  We've never released ePTID, and
they fell back to the subject nameID.  At some point in the distant past
our config was changed to send the persistent subject nameID in preference
to the transient nameID, so logins worked.  Then they broke when we started
generating different values.

The underlying problem was something that didn't jump out to me the first
several times I looked at it.  Our old saml-nameid.properties contained:

idp.persistentId.salt = “this value has been redacted”


The new one had the quotes stripped, a mistake in the way I set up the
Ansible playbooks:

idp.persistentId.salt = this value has been redacted


-Les

<http://www.carleton.edu/>

*Les LaCroix '79*

Strategic Technologist

Information Technology Services

t: (507) 222-5455


On Mon, Feb 22, 2021 at 2:01 PM Les LaCroix <llacroix at carleton.edu> wrote:

> Scott and Peter, thank you for your responses.  You confirmed that it
> wasn't an obvious mistake that I missed.  Thanks!
>
> I'm going to go down a different path, namely one of not caring.  Since
> late August, my users have logged in to 5 SPs that specifically request a
> persistent nameid.  Of the five, two have a special nameid generator
> because they demand that the nameid is actually an email address or eppn.
> Two others I know for sure that they look at attributes and not the
> subject.  I'm willing to bet that the final one also doesn't care about
> the nameid in the subject, since its metadata lists eppn, epuid, and eptid
> among the requested attributes.
>
> -Les
>
> p.s. I determined that my problem wasn't introduced when I tried to
> upgrade to v4, but sometime before then.  I still don't know what I did to
> create the problem: the relevant properties are the same, and as far as I
> can tell, we've never made changes to the c14n
> configs.  idp.persistentId.generator has always been commented out in
> saml-nameid.properties.  But I don't think I care.
>
>
> <http://www.carleton.edu/>
>
> *Les LaCroix '79*
>
> Strategic Technologist
>
> Information Technology Services
>
> t: (507) 222-5455
>
>
> On Mon, Feb 22, 2021 at 7:26 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
>> Basically that's all impossible, so that leaves "something you think is
>> the same isn't", and there's not really any way to debug that but you.
>>
>> The inputs to the calculation are obviously the principal, salt, and SP
>> entityID, and then the digest and encoding. One of them's not the same,
>> that's really all there is to it.
>>
>> I would maybe be looking at principal name and perhaps see if subject
>> c14n is not doing what it was doing originally.
>>
>> -- Scott
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210304/891be4ad/attachment.htm>