shibboleth.SAML2PersistentGenerator question

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

shibboleth.SAML2PersistentGenerator question

Shibboleth - Users mailing list
Background: I tried to upgrade an old 3.3.0 IdP to 3.4.*, which had a lot of cruft in it from upgrades that were maybe not done well ever since the 2.* days.  It all works great, EXCEPT logging in on Windows to MicrosoftOnline in Office apps fails about 50% of the time, and three months of debugging with help from Unicon and Microsoft didn't solve it.  So I came at it from the opposite angle: start with a clean v4.0.1 installation (based on the TAP container) and reintroduce changes into the v4 config.  That approach is working so far (MSOnline logins seem to work flawlessly), EXCEPT my SAML2PersistentGenerator nameid generator isn't producing the same results as reported by aacli.sh.

I have verified that saml-nameid.properties contains the same values for idp.persistentId.sourceAttribute, idp.persistentId.algorithm, and idp.persistentId.salt, and that the bean reference for shibboleth.SAML2PersistentGenerator is present (not commented out).  I even tried adding "idp.persistentId.encoding = BASE64" to saml-nameid.properties, even though the newly generated value looked to be base64 anyway (contained both upper and lower case).

I also added the source attribute to the filter for the relying party I'm testing against, and verified that it has the value I expect.

What else might I need to do?  Thanks, -Les

Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibboleth.SAML2PersistentGenerator question

Peter Schober
* Les LaCroix via users <[hidden email]> [2021-02-20 01:27]:
> I have verified that saml-nameid.properties contains the same values
> for idp.persistentId.sourceAttribute, idp.persistentId.algorithm,
> and idp.persistentId.salt, and that the bean reference for
> shibboleth.SAML2PersistentGenerator is present (not commented out).  I even
> tried adding "idp.persistentId.encoding = BASE64" to
> saml-nameid.properties, even though the newly generated value looked to be
> base64 anyway (contained both upper and lower case).

IDPv4 comes with "idp.persistentId.encoding = BASE32" set in
conf/saml-nameid.properties so the only explanation I'd have for the
new code to be using BASE64 without you setting this anywhere yourself
would be when using previously stored/persisted values.
But then you said "newly generated value" so that doesn't apply here
either.
Still, what is idp.persistentId.generator set to in both your old and
new systems?

> my SAML2PersistentGenerator nameid generator isn't producing the
> same results as reported by aacli.sh.

Are you saying calling aacli for a given subject and entityID produces
different persistent NameID values on the command line from those the
IDP releases for that same subject to the same SP -- and based on
what, the IDP's audit log? During transmission (in the
browser, assuming unencrypted Assertion/Reponse)? From the SP-side?

> I also added the source attribute to the filter for the relying
> party I'm testing against, and verified that it has the value I
> expect.

You may have done this solely for debugging purposes but I'll still
note that releasing the source attribute for a persistent NameID is
neither required or suggested: Doing this totally undermines the
purpose of generating and releasing only derived, opaque, SP-specific
values to the SP.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibboleth.SAML2PersistentGenerator question

Cantor, Scott E.
In reply to this post by Shibboleth - Users mailing list
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


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibboleth.SAML2PersistentGenerator question

Shibboleth - Users mailing list
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.


Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455



On Mon, Feb 22, 2021 at 7:26 AM Cantor, Scott <[hidden email]> 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



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: shibboleth.SAML2PersistentGenerator question

Shibboleth - Users mailing list
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

Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455



On Mon, Feb 22, 2021 at 2:01 PM Les LaCroix <[hidden email]> 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.


Les LaCroix '79

Strategic Technologist

Information Technology Services

t: (507) 222-5455



On Mon, Feb 22, 2021 at 7:26 AM Cantor, Scott <[hidden email]> 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



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]