Sign in Error in Emulator

[mahathota]

Request Id: 0a4a2a1f-bded-4014-be5e-01694f622600 Correlation Id: c66a3377-3589-44eb-9e26-52e53b31aab7 Timestamp: 2021-04-09T17:21:41.550Z App name: iris-webbot-ppe App id: c98b4c80-5de7-4cc5-8b8d-f76b16e121da IP address: 67.160.99.221 Device identifier: Not available Device platform: Windows 10 Device state: Unregistered

[dmvtech]

Hi @mahathota Can you please share more information about what you were attempting to do when you received the error? What are you signing in to? Is this using a sample, or your own bot?

We need more information to determine what is going on.

[jsia9]

same here. run the bot composer , then open the emulator then click on sign in. on mac with the latest version. Failing to load 69.js

[dmvtech]

@jamalsia Newest version, I assume you're using 4.12.0 (4.13.0 released today). Not reproducing for me on either 4.12 or 4.13 on Windows. I don't have a Mac to test on. I'll investigate possible causes.

@mahathota What version of Emulator are you running?

[tonyanziano]

The failed to load 69.js is not relevant to auth, it is part of the Monaco editor that we use to display the custom activity editor.

It is very possible that this scenario is broken due to a company wide policy change that also affected Composer in late 2020.

[jsia9]

hi @dmvtech . So Ive upgraded to 4.13.0 and it worked from the first login. @tonyanziano , the js was not an issue as you said.

so i guess might be related to some caching. if you try to login the first time and the login fails then it will keep calling this page https://dev.botframework.com/cb%7D which returns the 404 i am not sure why this is so.

[tonyanziano]

Now that you mention the /cb URL, it sounds like this could be related to ##2247, and #2248

[tonyanziano]

Please try this auth flow in our newest build: v4.13.0

This contains PR #2248 which should have fixed this.

[jsia9]

@tonyanziano yes, thanks loads. Ive upgraded to 4.13.0 and it worked from the first login.

[tonyanziano]

Glad to hear it! Going to close this.

[mahathota]

Getting same error after upgrade.

[tonyanziano]

@mahathota That error looks very similar to the error we were seeing in Composer before integrating a new authentication library (https://github.com/microsoft/BotFramework-Composer/pull/4677).

Do you have a personal account (non @microsoft.com) you can try to sign-in with?

[dmvtech]

Hi @mahathota Just checking to see if you have a personal account to test with per @tonyanziano

[dmvtech]

Closing for now. @mahathota If you still having this when testing with a personal account, please comment and let us know.

[namanimsft]

@tonyanziano, I work with @mahathota and we are still having the issue with Sign In. Could you please help us?

[tonyanziano]

Hi @namanimsft ,

As I asked @mahathota , do you have a personal account (non @microsoft.com) you can try to sign-in with?

[namanimsft]

@tonyanziano, Nope, I don't have one.

[tonyanziano]

@namanimsft are you trying to use an OAuth sign-in card from your bot?

[namanimsft]

@tonyanziano Yes, we are using OAuth sign-in card in our bot

[tonyanziano]

I will try to reproduce this on my end with an OAuth bot.

[tonyanziano]

I have verified and reproduced the issue with my Microsoft work account (@microsoft.com), however I can bypass the issue using a personal account (@gmail.com).

This appears to be the same issue that we faced in Composer, and it is not trivial to fix. It involves leveraging an internal authentication library -- which involves major changes to our build pipeline -- and rewriting the way we handle OAuth sign-in cards.

There was a company tenant-wide policy that went out several months ago that prevents @microsoft.com accounts from signing in from certain desktop applications unless they use a specific authentication method. Teams encountered this same issue.

For now, I would recommend setting up a personal MSA account to test with.

[namanimsft]

@tonyanziano, Thanks for the update. Our bot is for internal Microsoft employees who works for Microsoft customers at the fields. We've a integration with various internal Microsoft services including graph API, office api's, inhouse built APIs and all of them relying on AAD with MS employee profile. So, we heavily rely on @microsoft.com account

[tonyanziano]

@namanimsft I see. Sorry for the inconvenience!

The other alternative would be to deploy your bot and test it via Web Chat. The work flow is not as fast as locally developing and testing in Emulator, but at least Web Chat would allow you to test the OAuth sign-in scenarios.

[namanimsft]

@tonyanziano, Is there an ETA for this bug please? From our org, 5 teams got impacted because of this bug. We built our Bot as platform with one parent bot and multiple skills. Each skill owned by separate team. All of them struggling with dev & test work locally. Would be great, if you or your team could expedite fixing this bug. thanks!

[tonyanziano]

@namanimsft Unfortunately, implementing this fix would take at least a month, and could potentially break existing auth scenarios on other platforms like Linux, where the new auth library is not yet supported.

Our team is currently focused on porting over Emulator functionality into our comprehensive bot-building tool, Bot Framework Composer. As you can see from this screenshot, you can inspect bot traffic and test your bot inside the app with a very similar UI to the Emulator:

Since we are integrating major Emulator features into Composer, and the new authentication library is already implemented in that code base, it is more likely that Composer will support testing OAuth cards before it is fixed in Emulator.

That being said, we are still finishing up our current release cycle, and have not started planning for the following cycle yet, which would have a release date in the summer. So support in either application would be potentially months away.

---

The workaround for now would be to deploy your bot and use Web Chat to test the authentication scenarios, or possibly setup a dev environment in which personal accounts function the same as a work account.

Out of curiosity, how are these teams building bots? Are they using Composer or are they writing raw code using the SDKs? As I mentioned above, we are investing more into the bot testing functionality of Composer, and it might be worth considering building these bots with Composer in the future.

[namanimsft]

@tonyanziano, we are using BotFramework SDK v4 for .Net and its hard to move to composer for sure for now. We've started our journey from SDK v4-preview to its latest version now. Can I know why authentication got broken in emulator? Have not considered Microsoft tenant & @microsoft accounts while upgrading the authentication feature in Emulator? Practically breaking some feature which was already working is something hurting us.

[tonyanziano]

@namanimsft It was not something we implemented that broke authentication for work accounts. It was an all-up Microsoft AAD tenant-wide policy update that basically enforces all members of that tenant (@microsoft.com users) to log in from compliant environments.

We do not control the Microsoft tenant, the company does.

What this means for our users, and Microsoft employees in general, is that you can only login to your @microsoft.com account inside of Edge with your work profile linked, or in the case of a desktop application, using special operating system-level security features.

Since our application is a desktop application built with Electron, which uses Chromium as the underlying browser, this scenario is broken.

To fix this, we have to use a Microsoft-vetted authentication library which uses these special security features in the operating system to authenticate with work accounts. Teams ran into this same exact issue because they are also built on top of Electron. We faced this same issue in Composer as well. Authentication scenarios were working, and then they were suddenly broken because of this change in AAD.

The fix is to rewrite our authentication functionality to use one of these new libraries, an exercise which we already have done in Composer, and it is not a trivial amount of work.

Hope this clears things up.

[namanimsft]

@tonyanziano, First sorry for the late reply and thanks for the detailed information behind this bug. Please see if you or your team can consider this as one of the top priority bug to help us unblocked. I'm sure this would've impacted many teams with in Microsoft. Also keep this bug open until this is sorted out. Thanks!

[tonyanziano]

@namanimsft I will bring this up in our next planning meeting

[nisha-s-patel]

Hi @tonyanziano, do you have any updates on this issue? My team has been having this same error ("you can't get there from here") and we too rely on the corp @microsoft.com accounts for use with all of our customers. We were directed here by the Microsoft Help Desk. If there's any additional information I can provide, please let me know.

[tonyanziano]

Hi @nisha-s-patel ,

Unfortunately, this issue has not been included in our list of planned work items for the upcoming release cycle.

As of right now, I can only refer you to the proposed workaround above:

The workaround for now would be to deploy your bot and use Web Chat to test the authentication scenarios, or possibly setup a dev environment in which personal accounts function the same as a work account.

[namanimsft]

Hi @tonyanziano, Would be great if you or your team consider this one of the priority bug. Let me know if you need any information or justification from our end would help you to push this bug in the priority please. Thanks!

[praveenvavilla]

hi @tonyanziano we also facing the same issue and our chat bot is only for Microsoft internal employees, it would be nice if this considered as high priority . Also worth mentioning that , log in flow works with bot implemented from V3 and looks like this happens only with bots implemented on V4. Thanks