IdP service interruption: LDAP source using private CA

David Bantz dabantz at alaska.edu
Mon Apr 1 16:04:06 EDT 2013


Thank you Scott.  This is helpful information for today's work…

I like the idea of failover to static connector as a fail-safe and will look into that after today's fire is out.

David

On Mon, 1 Apr 2013, at 11:42 , "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> 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
> 
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net



More information about the users mailing list