Error in the idp-process.log

[Cantor, Scott]

> Could the following old AttributeDefinition clash with the new StoreID - listed
> below in the thread? The old derives the 'uid' from a straight LDAP query --
> with no persistent configs.

I don't really understand what you're asking, but the "new" StoredId is not new.

> I am still puzzled as the new StoreID writes & salts to the DB (which we did
> not have previously).

You have the old legacy resolver configuration with the StoredId connector, which is functionally equivalent to following the documentation for using a stored strategy for generating the IDs using the new properties and Spring beans in V3. Same underlying logic, for compatibility.

Maybe you didn't have it previously but the "new" thing in attribute-resolver.xml is not a new thing, it's the old thing. You have it in there with all the property replacement expressions, but that's not anything we give you. A V2 config would have had the same StoredId data connector there but the settings would have all been inline.

So somebody cooked up a concoction of combining the old legacy connector with the new properties. None of that is what we document or supply as examples in V3. It works, and I'm assuming that's what's making it functional in spite of the errors.

The bottom line is that your NameID generation config is broken. I can't tell you why, you have to follow the Spring errors to the offending bean name and see what's wrong with it. But if you get that fixed, it's quite possible system behavior could change, so you have to do that in a test environment and evaluate the behavior at that point.

Fundamentally if you're trying to "undeprecate" things, you would have to remove all mention of NameIDs from the resolver, and that will lead you to a non-functional state that can hopefully then be fixed to behave the way it was. But you're free to keep using the resolver features from V2 and keep it working for the time being, but then I would still get rid of all the newer settings being used and make sure the Spring errors are gone.

-- Scott