Error in the idp-process.log

[ls Lidz]

Thanks Scott!

That could be it ---- I inherited the service so have not touched other
nameID configs -- worried that may break other things.

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 am still puzzled as the new StoreID writes & salts to the DB (which we
did not have previously).


 <resolver:AttributeDefinition id="NameID" xsi:type="Simple" xmlns=
"urn:mace:shibboleth:2.0:resolver:ad" sourceAttributeID="uid">

      <resolver:Dependency ref="ldapLookup" />

      <resolver:AttributeEncoder xsi:type="SAML2StringNameID"

      xmlns="urn:mace:shibboleth:2.0:attribute:encoder"

                nameFormat=
"urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />

       </resolver:AttributeDefinition>

On Thu, Jul 20, 2017 at 2:18 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > Here is the odd thing -- rebooting, without changing config files, still
> works
> > for all -- including PersistentID -- & the error message still occurs on
> a
> > scheduled basis.
>
> I think you have a non-failfast NameID generation service config, and you
> have a legacy resolver configuration that's doing NameID generation and
> it's basically backstopping and doing the work you think these settings are
> doing. I can't think of any other obvious answer.
>
> > Quite stumped......is there something not right in config below?
>
> There's nothing anybody could eyeball, this is a Spring runtime error in a
> system bean whose problem is with the runtime behavior of the components, I
> doubt it's a syntactic problem.
>
> > attribute-resolver.xml
>
> Thus my point. There is nothing in attribure-resolver.xml that has
> anything to do with a system that's supposed to be operating based on the
> saml-nameid files and properties. You pick one, not both. Old, new. You
> will find nothing in the NameIDGeneration topics that refer to the resolver
> or expect you to set anything there, so you are inherently doing something
> we do not expect you to do.
>
> Probably one's working and one isn't. I thought we normally set the
> generation service to fail-fast, but I don't have it in front of me.
>
> Basically, your system is not using the settings you seem to believe it
> is. You're changing settings for the new features, it's not functioning,
> and the old settings in the resolver that are deprecated are still there
> and running.
>
> -- Scott
>
> --
> 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/20170720/7b4e95a4/attachment.html>