idp-war-3.4.4.war in Maven Repo is bad

[Dan McLaughlin]

I get where you're coming from.  Maybe update the release notes to let
people know that if they got the idp-war from Maven they will still
need to download and install the ldaptive jars and put them in their
classpath as was discussed in one of the related ticket on the topic.

As to why adding the new property is causing failures, I still haven't
figured out why yet. It looks like I narrowed down the failures to
something related to us using JAASAuthnConfig.  If you are using
LDAPAuthnConfig then it works.    Unfortunately we have to use
JAASAuthn because there's no other way to chain different user
repository types using the LDAPAuthn config and we have the need to
authenticate users against a database user repository and only if they
aren't in the database do we try LDAP.  The only way we could figure
out a way chain a database and LDAP was using JAAS Authn. One thing to
note is that it doesn't seem to break the JAAS Authn, but it would
seem that something with the attribute resolution breaks. We can see
in the logs that the login is successful, it's not until it gets to
the attribute resolution that things error out.   Anyways, still
digging, but if you think of anything that might explain the behavior
I'm seeing I'd be open to any suggestions.

Thanks again!

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
dmclaughlin at tech-consortium.com
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

On Thu, Jun 13, 2019 at 8:37 AM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> > They actually did it for the logging runtime dependencies and add the ldaptive dependencies into
> > that same plugin execution.
>
> They are the same issue; the software as it stands does not require any specific LDAP or logging implementation, and it is only our distribution that provides specific instantiations that match our defaults, as Ian noted. Whatever is correct for the logging is also conceptually correct for the LDAP jars, particularly in V3 where Unbound isn't the default.
>
> > On a side note the step to add idp.ldaptive.provider =
> > org.ldaptive.provider.unboundid.UnboundIDProvider to the
> > ldap.properties in 3.4.4 doesn't just work as the release notes would
> > lead you to believe.
>
> In most cases, that works. In other cases, you may have JNDI-specific assumptions that have to be adjusted, but that's a local matter. In all cases, it does what the Release Notes are trying to say, which is that it does switch the provider without having to do so externally. It doesn't mean to say that's the only possible change needed, that's why it refers to the other page.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net