Monitoring Native Shibboleth Authentication

[Izz Noland]

Thank you Scott.  That pretty much answers all questions I had.  I've been meaning to install an IdP locally, and this really helps that cause.

Cheers!

Izz Noland
Sr. Systems Engineer

izz.noland at wepanow.com
Toll Free 1(800)675-7639
100 Gilbert Drive | Alabaster, Alabama 35007

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Friday, July 24, 2015 1:26 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Monitoring Native Shibboleth Authentication

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

-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net