shibboleth.SAML2PersistentGenerator question

[Les LaCroix]

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/20210222/cfe8007f/attachment.htm>