IDP health check

Rainer Hoerbe rainer at hoerbe.at
Mon Feb 27 10:13:56 EST 2017


> Am 27.02.2017 um 15:30 schrieb Cantor, Scott <cantor.2 at osu.edu>:
> 
>> test 3: shut down ldap after successful start of idp; try to login
>> UI:	Login Failure: javax.naming.CommunicationException: connection
>> closed
>> /idp/status: DataConnector idpLDAP: has never failed
> 
> That's an attribute resolver check, not authentication. We don't have any validation hooks in place for the authentication layer. I would like to fix that, but it's very awkward, the flow approach doesn't lend itself to that.
> 
> The status check doesn't currently actually revalidate the connectors either. That might be doable, not sure, but that seems like a gap/bug, I agree.
> 
>> test 4:  start idp while ldap is unavailable
>> idp-process.log: Uncaught runtime exception
>> /idp/status: HTML error page
>> idp recovers when starting ldap, but status page keeps failing
> 
> The behavior depends on a lot of configuration factors (I don't have my IdP set up to fail like that, for example). An HTML error is likely a bug somewhere, unless the context just didn't initialize, but that doesn't fit what you're saying. I don't know why it would keep failing. I'd be more concerned about the metric hooks anyway, the status page is somewhat deprecated, or will be, once the metrics are more firmed up.
> 
> In any case, the answer to your question is that the best way to monitor it all is to script a login to a service. Anything else is really a lot of extra effort to end up in the same place.
> 
> Obviously that's screen scraping (unless you use the ECP shell script as a test), but since it's your IdP, that's not so much a concern.

Screen scraping is not the problem, as the SAML test harness does this quite well. I wanted to avoid to bundle the whole test harness into the shib-idp container doubling the Dockerfile. But if this is the way to go, no problem.

Thanks, Rainer


More information about the users mailing list