In most cases authentication via LDAP (including the Microsoft implementation that comes with "Active Directory") will be easiest and most useful:

Adjust /opt/shibboleth-idp/conf/ to taste, according to section "General Configuration" from the documentation.

The properties file /opt/shibboleth-idp/credentials/ by default contains the setting idp.authn.LDAP.bindDNCredential to be used for the password of the administrative account performing LDAP binds. In case you're planning to use the bindSearchAuthenticator authentication strategy in your (with a given idp.authn.LDAP.bindDN) make sure to set the corresponding password for that DN in credentials/!

If OTOH you intend to use the anonSearchAuthenticator in (only anonymous binds will be made to the configured LDAP server/s) be sure to remove the principal and principalCredential XML attributes from your LDAP DataConnector in your /opt/shibboleth-idp/conf/attribute-resolver.xml (as included in our documentation and also in conf/examples/attribute-resolver-ldap.xml).

In order to test/verify your authentication configuration use the methods described in our Testing an IDP documentation.

Further reading for more advanced needs:

E.g. you may be interested in the automated account lockout feature (even though this allows anyone to DoS individual accounts simply by repeatedly providing an incorrect passwort for given accounts), see Account Lockout under Advanced Features in the Shibboleth IDP documentation. In the simplest case you just need to uncomment the bean with id="shibboleth.authn.Password.AccountLockoutManager" in the file /opt/shibboleth-idp/conf/authn/password-authn-config.xml (and optionally adjust the parameters to taste). The page for Account Lockout Management explains how to lock/unlock accounts via HTTP and therefore also from the command line using cURL.

As always, after having made changes to any property files you'll need to restart the whole container (i.e., Tomcat) for the changes to become active:

systemctl restart tomcat9
  • No labels