<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mon, 1 Apr 2013, at 11:42 , "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On 4/1/13 1:14 PM, "David Bantz" <<a href="mailto:dabantz@alaska.edu">dabantz@alaska.edu</a>> wrote:<br><blockquote type="cite">... failure to bind to the AD LDAP during attribute</blockquote><blockquote type="cite">resolution aborts the attribute resolution<br>process, so that no attributes at all are encoded in the SAML assertion.<br>Is there a way to configure the IdP attribute resolution to be less<br>fragile - that is, to enable encoding and release of those attributes<br>that can be resolved without the second AD LDAP?<br></blockquote><br>For actual connection failures, yes, you need Failover connectors to fall<br>into. If you have to back those up with something completely safe, you can<br>configure dummy connectors using "Static" that just return a dummy<br>attribute.<br></blockquote><br></div><div>This seemed a good idea, so I configured a fail-over DataConnector as per</div><div><a href="https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverRDBMSDataConnector">https://wiki.shibboleth.net/confluence/display/SHIB2/ResolverRDBMSDataConnector</a></div><br><div>But failover does not appear to cover the case of connection failure due to untrusted certificate:</div><div>the attribute-resolver aborts encountering an untrusted certificate; in fact the IdP startup process</div><div>itself aborts encountering untrusted certificate in the DataConnector.</div><div><br></div><div>Am I missing something, or is it just the case that receiving an untrusted certificate in a connector</div><div>is a fatal error for the IdP?</div><div><br></div><div>David Bantz</div><div>U Alaska</div></body></html>