Logging Untrusted Providers

[Nate Klingenstein]

Actually, that error message might be accurate after all.  The first set of DEBUG statements may have been from the first query, while the ERROR was thrown after the second.  I bet it's the form action that's broken.

On Jul 1, 2014, at 4:42 PM, Nate Klingenstein <ndk at internet2.edu<mailto:ndk at internet2.edu>>
 wrote:

It's still a confusing error message, so if there's something that can be done, that would be nice.  Even the old SAML 2 SSO Profile is not enabled for blah blah was a little better than this because it kinda sorta pointed where to go.

All my interaction with the IdP has been with the old test.py saml2sso_idp script that Chad wrote, so there is no back button.  But right now, it's having trouble issuing the POSTed login credentials.  I'm trying to figure out what changed there between v2 and v3, but it's apparently performing a replay itself for some reason.

7/1/14 10:32:34 PM (thread 0 run 0 test 2): sending login request to: https://IdPv3LoadTestingELB-1265594674.us-west-2.elb.amazonaws.com/idp/profile/SAML2/POST/SSO;jsessionid=1q8jo609mj7ok14mots8qwjgfm?execution=e1s1<https://idpv3loadtestingelb-1265594674.us-west-2.elb.amazonaws.com/idp/profile/SAML2/POST/SSO;jsessionid=1q8jo609mj7ok14mots8qwjgfm?execution=e1s1>
7/1/14 10:32:34 PM (thread 0 run 0 test 2): Request URL = https://IdPv3LoadTestingELB-1265594674.us-west-2.elb.amazonaws.com/idp/profile/SAML2/POST/SSO;jsessionid=1q8jo609mj7ok14mots8qwjgfm?execution=e1s1<https://idpv3loadtestingelb-1265594674.us-west-2.elb.amazonaws.com/idp/profile/SAML2/POST/SSO;jsessionid=1q8jo609mj7ok14mots8qwjgfm?execution=e1s1>

-> Login page comes back again; script does not proceed and treats it as a failed run.  This is the action in login.vm:

            <form action="$flowExecutionUrl" method="post">

and it renders as:

           <form action="/idp/profile/SAML2/POST/SSO?execution=e1s1" method="post">


On Jul 1, 2014, at 4:31 PM, "Cantor, Scott" <cantor.2 at osu.edu<mailto:cantor.2 at osu.edu>>
 wrote:

Or it's just the back button. The common errors resulting from that will
probably be suppressed by default, but there's no way to distinguish
unintentional from intentional.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140701/c8424688/attachment.html