jaas+krb5 vs krb5 backed password authentication

[Liam Hoekenga]

I'm trying JAAS+krb5 backed authentication on a few of our non-prod IDPs,
and something very strange is happening... it doesn't actually seem to be
doing password validation.  It accepts any provided password as valid for
any user.  If the principal given exists in our LDAP store, it gets
attributes.  If it doesn't, it just logs the user in.  What the what?

2019-03-26 18:57:03,471 - 141.213.171.216 - DEBUG
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstJAAS:244] -
Profile Action ValidateUsernamePasswordAgainstJAAS: Attempting to
authenticate user 'xxx.xxx.xxx.xxx' via 'ShibUserPassAuth'
2019-03-26 18:57:03,471 - 141.213.171.216 - DEBUG
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstJAAS:340] -
Profile Action ValidateUsernamePasswordAgainstJAAS: Using custom JAAS
configuration type JavaLoginConfig with parameters of type
java.security.URIParameter
2019-03-26 18:57:03,483 - 141.213.171.216 - INFO
[net.shibboleth.idp.authn.impl.ValidateUsernamePasswordAgainstJAAS:247] -
Profile Action ValidateUsernamePasswordAgainstJAAS: Login by
'xxx.xxx.xxx.xxx' via 'ShibUserPassAuth' succeeded

Nonexistant principals look exactly the same.

Here's our jaas.config...

ShibUserPassAuth {
    com.sun.security.auth.module.Krb5LoginModule required
        refreshKrb5Config=true
        useKeyTab=true
        keyTab="/usr/local/mcomm/shibboleth-idp/credentials/keytab"
        storeKey=true
        principal="HTTP/shibboleth.umich.edu at UMICH.EDU"
        doNotPrompt=true;
};

If password-authn-config.xml is set to use the krb5 backend, invalid
passwords are rejected, as expected.  So.. I don't think this is due to our
mfa config or intercept flows, etc.

I cannot replicate it with the sql-backed JAAS mechanism that we're
developing.
I have not yet tried with an LDAP backed JAAS config.

I stripped back our branding, our extra intercept flows, and the addition
of the OIDC extension.  I'll try it on vanilla install (with enough config
to authenticate), but this is baffling.

Any ideas?

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190326/afdc5e5a/attachment.html>