Monitoring Native Shibboleth Authentication

Cantor, Scott cantor.2 at osu.edu
Fri Jul 24 14:26:05 EDT 2015


On 7/24/15, 2:16 PM, "users on behalf of Izz Noland" <users-bounces at shibboleth.net on behalf of izz.noland at wepanow.com> wrote:

>Understood.  I wasn't planning for one script to accommodate each possible scenario.  In our case, we have huge confidence that if one IdP is able to login, then all should be able to, unless the problem is on the other end.

Right, so usually what I would suggest is simply run an IdP and use it for monitoring.

>With your reference to "every possible HTML scenario on the other end," I am assuming you are referencing the form IDs for username / password and submit?

Mostly. It's not that simple, an IdP could be sending control off to other systems for login, and there could be multiple cookies involved.

>If I am able to use curl to post, would storing the cookie be necessary in order to check the /Session page?

Cookies are involved on both ends.

>  This was briefly discussed in InstallFest, but because there are n+1 implementations where n = federated entity, I was left with an impression that using bash (as is being done with a research entity in EU), there would be a way to take advantage of the ECP endpoint / assertion consumer service to accomplish my goal.

That also works, if the IdP supports ECP, but still involves a cookie at the SP.

-- Scott



More information about the users mailing list