Add a common implementation for the BrokerRestrictionsManager, Fixes AB#3181005

[p3dr0rv]

Context

Currently, for QR + PIN authentication, users are prompted for camera permission every time the camera is used, even if OS-level permissions are granted. This is a CELA requirement to ensure user consent. However, a new feature request aims to suppress this camera permission prompt if an admin enables a specific flag in the restriction manager of the authenticator app.

Changes

• The current PR involves refactoring the RestrictionsManagerHelper class to make it reusable for reading the new flag.
• Create a new class, CommonBrokerRestrictionsManager, that implements the IBrokerRestrictionsManager interface.

Upcoming PRs will leverage this flag to implement functionality that suppresses the camera permission prompt when enabled by the admin.

Related PR: https://github.com/AzureAD/ad-accounts-for-android/pull/3066
AB#3181005

[github-actions]

❌ Work item link check failed. Description does not contain AB#{ID}.

Click here to Learn more.

[mohitc1]

RestrictionsManagerHelper

If you're going to use this in WebViewAuthorizationFragment, how will it work in OneAuth only flow?

[p3dr0rv]

If we are in a non-broker flow, we do not call RestrictionsManagerHelper for this QR PIN scenario, checking the Activity type that contains the fragment.

However, in a hypothetical scenario where RestrictionsManagerHelper is used in a non-broker flow:

1. Requesting data from a broker app: will make an IPC call to the broker app, read the Restrictions manager from there, and return the result.
2. Requesting data from the current app: will read the Restrictions manager of the app, which will likely be null.

[mohitc1]

I raised this because I feel like this is broker only component is being put in common and can potentially run in non-brokered flow. It would be better if could inject an object in common layer (or WebViewAuthorizationFragment in this case) to customize behavior for broker vs other. It's general problem that is seen on other cases as well e.g. nonce redirect handling, flighting

I guess, it might be too much work if you do that in this PR?

[mohitc1]

Q: For what would be logic for non-broker flow?

[p3dr0rv]

for non-broker flow we do not check the restriction manager, and we just grant the camera permission if we have it.
But even if the component were called in a non-broker flow it will keep working as I change it to only read RestrictionsManager from broker apps