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