IdP service interruption: LDAP source using private CA

[Cantor, Scott]

On 4/1/13 1:14 PM, "David Bantz" <dabantz at alaska.edu> wrote:
>
>(1) Will this affect ONLY the login portion, or will this also enable use
>of the same LDAP in attribute resolution?

Depends how you configure the LDAP connector (refer to the vt-ldap
documentation for the gory details), but a simple fix that works by
default is using the JDK cacerts file, yes.

There are many ways to do it.

>(2) The syntax of the statement is that the certificate itself is
>imported using keystone, not the CA certificate.  I am told that part of
>the process of using these private CA certificates is to automatically
>create and put in place new certificates on
> a routine daily basis, so the IdP would need to import a new certificate
>every day to use this AD LDAP source.

If something is self-signed, the CA is the certificate. If not, you can
import the CA.

>(3) Logs show that the IdP successfully authenticates users against the
>other LDAP, and successfully retrieves users'  attributes from that
>directory.  However, the failure to bind to the AD LDAP during attribute
>resolution aborts the attribute resolution
> process, so that no attributes at all are encoded in the SAML assertion.
> Is there a way to configure the IdP attribute resolution to be less
>fragile - that is, to enable encoding and release of those attributes
>that can be resolved without the second AD LDAP?

For actual connection failures, yes, you need Failover connectors to fall
into. If you have to back those up with something completely safe, you can
configure dummy connectors using "Static" that just return a dummy
attribute.

-- Scott