<div dir="ltr">Hi,<div><br></div><div>Further to above and as per your suggestion, I removed Shibcas and introduced below in SAML2.SSO profile and it works</div><div><br></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif">p:authenticationFlows="#{{'Password'}} </span><br></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div><font face="Calibri, sans-serif"><span style="font-size:11pt">it appears the two </span><span style="font-size:14.6667px">re-directions</span><span style="font-size:11pt"> happening form IdP to CAS and CAS to IdP, something getting missed in between</span></font></div><div><br></div><div>Issue is, Even though though the CAS login comes in the embedded window still it is SAML2.SSO profile, and we got Password authentication flow for only for the ECP profile. Changing to Password will change the user behavior for this replying party in other areas.</div><div><br></div><div>So is there any way to detect (by some means) this flow and have a different relying Party or any other suggestion, basically no issues providing Password flow for this interaction as well.</div><div><br></div><div>Please advice.</div><div><br></div><div>Thanks</div><div><br></div><div><font face="Calibri, sans-serif"><span style="font-size:11pt"><br></span></font></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div><div><span style="font-size:11pt;font-family:Calibri,sans-serif"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 1:40 PM, Lalith Jayaweera <span dir="ltr"><<a href="mailto:ljayaweera@gmail.com" target="_blank">ljayaweera@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Scott,<div><br></div><div>I observed an similar discussion in below thread, kind of similar failure after IdP version upgrade</div><div><br></div><div><a href="http://shibboleth.1660669.n2.nabble.com/NoSuchFlowExecutionException-with-office365-apps-td7634076.html#a7634086" target="_blank">http://shibboleth.1660669.n2.<wbr>nabble.com/<wbr>NoSuchFlowExecutionException-<wbr>with-office365-apps-td7634076.<wbr>html#a7634086</a> <br></div><div><br></div><div><br></div><div>Things working in IdP V2 as you mentioned could be due to loose unsupported auth modules accepting malformed requests? Or could it also be in IdP V3, we are overly restrictive?</div><div><br></div><div>I am not sure will it help, I will try to take off CAS and see.</div><div><br></div><div>This particular issue is only on Mac and on Windows it works.</div><div><br></div><div>Thanks</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 10:42 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 8/2/17, 8:27 PM, "users on behalf of Lalith Jayaweera" <<a href="mailto:users-bounces@shibboleth.net" target="_blank">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:ljayaweera@gmail.com" target="_blank">ljayaweera@gmail.com</a>> wrote:<br>
<br>
> Don't you think this issue is specific to IdP 3.3.x? Or in other words it should also fail on IdP 2.4.x if the request is malformed.<br>
<br>
</span>The bug is almost certainly in the client. The result of the bug is dependent on the the state management architecture, and how the application framework deals with improper access, replay, stale requests, and a variety of other things. It works how it works, and buggy clients can break it in all sorts of ways. After lots of tracing and packet analysis, it's likely that the cause would be found, and the end result would be that the client was broken and there isn't really anything we could likely do about it anyway.<br>
<span><br>
> On another note, if we promote IdP 3.3.x to production this feature (Office 365 product activation) will fail on Mac,<br>
<br>
</span>I have no experience with Office 365, but if others do, I guess they could tell if they're having the same issue.<br>
<span><br>
> As a side note, what I am trying is, when the office 365 software downloaded, am try to activate it, in this process, it asks to enter<br>
> the email address and then it does the discovery and goes to the CAS login screen, all these happening(browser rendering)<br>
> within their UI controller,<br>
<br>
</span>Did you try it without CAS? I don't think that's related, but if it were, that's not really anything we support, and it's possible that the client bug involves it dropping a cookie during the handoff between the systems.<br>
<span><br>
> Is there any way to find the difference in these two versions and find a way thru for IdP V 3?<br>
<br>
</span>The difference is they are completely different pieces of software with virtually nothing in common in the layers involved here. I have no way through to give you, unless it turns out that the use of an unsupported authentication module turns out to be involved. That is certainly the first thing I would check to at least rule it out.<br>
<br>
> Error below.........................<wbr>.....<br>
<br>
Your problem is almost certainly with cookies, but there is nobody else who can trace and diagnose it. You would have to trace all of the interactions and look for a mistake by comparing a proper client with the broken one.<br>
<br>
Microsoft's track record with embedded clients is that they don't process redirects and cookies properly. Since that's the usual cause of this error, I have no reason to think anything else.<br>
<div class="m_-2439952558816186996HOEnZb"><div class="m_-2439952558816186996h5"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.n<wbr>et</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>