Error in the idp-process.log

[ls Lidz]

Thanks Scott!

Very helpful -- and much appreciated -- you helped me find error on my side.

1) The idp.persistentId.dataSource in the saml-nameid.properties -- had a
naming mismatch with value in global.xml.

I am not sure how the PersistentID was recorded in the database with
above mismatch -- my guess is that the data source in global.xml still
kicked in.

2) I am also bitting the bullet and converting the existing SPs to using
the 'StoredPersistentIdGenerator' from the computed.

I am not sure if 1 or 2, or both, were the root cause -- am too exhausted
to whittle away at this now -- but together problem solved.

I cannot overstate how much your emails helped -- thank you.

The salt in actual use is different -- wrote down value of my
daughter's favorite rhyme.


On Mon, Jul 24, 2017 at 1:47 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 7/21/17, 11:05 AM, "users on behalf of Cantor, Scott" <
> users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:
>
> > Ok, first conclusion: your original question:
>
> And my secondary points after having some time to review the code and the
> configurations posted:
>
> You cannot be getting NameIDs in the Subject element with a configuration
> whose NameID Generation service layer is failing and reporting errors of
> the type posted.
>
> That is also consistent with the fact that the configuration posted with
> legacy connectors inside the Attribute Resolver is not even trying to do
> that. It's generating the deprecated eduPersonTargetedID SAML Attribute [1].
>
> That is not the same thing as a SAML persistent NameID syntactically and
> doesn't depend on the NameID generation layer in the IdP, which is why it's
> "working". It's just not generating any NameIDs, and never was to begin
> with.
>
> I can't tell you what your services are depending on. When you have
> undocumented systems handed off, that loss of knowledge is obviously a
> serious problem. If you knew which services were relying on the Attribute,
> then it would be possible to reconfigure a test system to avoid all the
> deprecated pieces and see if things still work if it's passed in the
> Subject.
>
> -- Scott
>
> [1] https://wiki.shibboleth.net/confluence/display/SHIB2/
> NativeSPTargetedID
>
>
> --
> 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/20170725/be538803/attachment.html>