Office 365 App Registration Strange issue on Mac

[Lalith Jayaweera]

Hi,

Further to above and as per your suggestion, I removed Shibcas and
introduced below in SAML2.SSO profile and it works

p:authenticationFlows="#{{'Password'}}

it appears the two re-directions happening form IdP to CAS and CAS to IdP,
something getting missed in between

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.

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.

Please advice.

Thanks






On Thu, Aug 3, 2017 at 1:40 PM, Lalith Jayaweera <ljayaweera at gmail.com>
wrote:

> Hi Scott,
>
> I observed an similar discussion in below thread, kind of similar failure
> after IdP version upgrade
>
> http://shibboleth.1660669.n2.nabble.com/NoSuchFlowExecutionException-
> with-office365-apps-td7634076.html#a7634086
>
>
> 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?
>
> I am not sure will it help, I will try to take off CAS and see.
>
> This particular issue is only on Mac and on Windows it works.
>
> Thanks
>
>
>
>
>
>
>
>
> On Thu, Aug 3, 2017 at 10:42 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
>
>> On 8/2/17, 8:27 PM, "users on behalf of Lalith Jayaweera" <
>> users-bounces at shibboleth.net on behalf of ljayaweera at gmail.com> wrote:
>>
>> > 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.
>>
>> 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.
>>
>> > On another note, if we promote IdP 3.3.x to production this feature
>> (Office 365 product activation) will fail on Mac,
>>
>> I have no experience with Office 365, but if others do, I guess they
>> could tell if they're having the same issue.
>>
>> > 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
>> > the email address and then it does the discovery and goes to the CAS
>> login screen, all these happening(browser rendering)
>> > within their UI controller,
>>
>> 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.
>>
>> > Is there any way to find the difference in these two versions and find
>> a way thru for IdP V 3?
>>
>> 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.
>>
>> > Error below..............................
>>
>> 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.
>>
>> 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.
>>
>> -- Scott
>>
>>
>> --
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170803/70dc1abf/attachment.html>