microsoftconnect/intune-app-wrapping-tool-ios

Two different logins post wrapping the application

yogendrajs opened this issue · 6 comments

yogendrajs commented

Hi team, I've wrapped the iOS app with the latest version of the Intune App wrapping tool and have applied the App protection policy to it.

The current behavior is when the intended user opens the app, they're being shown an MS login screen post which they can access the app, but the app also has an internal username/password and/or SSO-based login flow. So the user ends up logging in twice. Is there a way to combine both logins? The current wrapped app doesn't use MSAL.

I investigated through the docs and StackOverflow but couldn't find a satisfactory answer. Please let me know if/how this could be achieved.

jamgarci-MSFT commented

The only way I am aware of to accomplish this would be with using MSAL as the app's authentication method.

  • 👍1
Kyle-Reis commented

@jamgarci-MSFT is correct. This would only be possible if the app were using MSAL to authenticate users, and even then, the preferred approach to achieving SSO with the Intune SDK would be to manually integrate the SDK rather than wrapping.

yogendrajs commented

Thanks, @jamgarci-MSFT @Kyle-Reis for the answer. If I use MDM also, will it still show the first MS login step to get inside the application or that will be skipped?

jamgarci-MSFT commented

Yes, you will see the first screen, which is MSAL, and then get redirected to the application.

  • 👍1
yogendrajs commented

Hi @jamgarci-MSFT @Kyle-Reis, I just had one small query. In the feature comparison docs between the App wrapping tool and the SDK integration, I couldn't understand much about the last point: Require app protection policy (Conditional Access), which is not available in the App wrapping tool.
Does it mean by App protection policy only? Because, I've wrapped the app and applied an App protection policy to it, which works as expected according to the rules defined in them. Can you please shed some light on helping with this?

Kyle-Reis commented

Hi @yogendrajs that item refers to the "Require App Protection Policy" conditional access grant in Microsoft Entra referenced in this doc:

https://learn.microsoft.com/entra/identity/conditional-access/migrate-approved-client-app

Admins can configure this CA requirement on resources within their tenant. When that is the case, the application will not be able to acquire a token for a resource that is gated behind this CA requirement unless it confirms with Microsoft Entra that it has successfully retrieved app protection policies for the user first. This protects the resource from potential admin misconfigurations which may have left the user untargeted with any app protection policy, or even a gap or delay between the user getting access to the resource and receiving the app protection policy, that may have been caused by an issue like poor network connectivity during the initial silent Intune enrollment attempt. This scenario really only applies to applications which use MSAL to acquire tokens and access resources in Entra, and the application's source code must call into the Intune SDK's APIs when it receives a response from Entra indicating that "require app protection policy" CA is applied to the resource. Therefore, wrapped apps could never support this since the original application's source code is unaware of Intune and does not call any of the SDK's APIs.

Since it sounds like your app is not using MSAL to acquire any tokens for any resources in Entra, this scenario would not apply to it.

  • 👍1