Provision vs DM Restrictions
Overview
AppsAnywhere allows you to assign restrictions to both provisions and delivery methods, but what if you apply them to both? In this article we'll explore the interaction between provision and delivery method based restrictions.
Restrictions provide the power behind smart prioritization as they allow you to strictly define the environments in which each delivery method can be used. Restrictions can also be added at the provision level for situations where a certain restriction applies more to a particular user (or group of users) rather than the app itself or any of it's delivery methods.
Naturally, the ability to apply restrictions to both delivery methods and provisions could easily lead to a situation where there are restrictions applied to both. This article will explain exactly how those restrictions will behave with each other in these situations so you can apply them with a full understanding of what the end result will be.
The Theory
AppsAnywhere takes a restrictive approach to any conflicts found between provision and delivery method restriction settings. For each given restriction (on-domain, on-site, user-owned), if a limit to how a delivery method can be accessed is set at any level (whether the provision level or the delivery method level) then that limit is enforced.
The Specifics
The following examples show exactly how restrictions interact in each scenario. In each table, the delivery method setting is on the left side and the provision setting is along the top. The value of each corresponding cell shows you how AppsAnywhere will enforce a restriction in each scenario.
On-Domain Restriction
Limitations of on-domain detection
On-domain detection is currently only supported for devices that are AD joined and an LDAP connection is configured with a matching domain.
On-domain detection is not currently supported for Entra joined devices or when SAML is used for authentication/authorization with no configured LDAP connection, including AppsAnywhere Cloud.
Prov. Enforced | Prov. Not Enforced | |
|---|---|---|
DM Enforced | Enforced | Enforced |
DM Not Enforced | Enforced | Not Enforced |
Example
If the provision that permits Group A access to a set of apps states that they can only be accessed whilst on-domain but some of the delivery methods defined for those apps permit off-domain use, the user will still not be allowed access to those delivery methods.
On-Site Restriction
Prov. Enforced | Prov. Not Enforced | |
|---|---|---|
DM Enforced | Enforced | Enforced |
DM Not Enforced | Enforced | Not Enforced |
Example
If the provision that permits a group of lab laptops access to a set of apps states that they can only be accessed when the device is on-site but some of the delivery methods defined for those apps permit off-site use (perhaps because those apps are also used for student access), those devices will still not be allowed access to the delivery methods if they are taken off-site.
Device Ownership Restriction
Prov. All | Prov. Inst. Owned | Prov. User Owned | |
|---|---|---|---|
DM All | All devices permitted | Institution Owned Only | User Owned Only |
DM Inst. Owned | Institution Owned Only | Institution Owned Only | NO ACCESS |
DM User Owned | User Owned Only | NO ACCESS | User Owned Only |
Example
If the provision that permits a group of users access to a set of apps states that they can only be accessed on user-owned devices, that doesn't necessarily mean they will be available on the user's device. Those delivery methods will only be available on a user-owned device if the delivery method restriction is also set to user-owned only, or it is not enforced and allows any device. If the delivery method restriction is set to institution-owned devices only, then the delivery method will be unavailable in all scenarios (under that provision).
Here we are comparing restrictions between provisions and delivery methods. The interaction of those restrictions is determining whether or not a particular delivery method is available. Keep in mind that there may still be other delivery methods available that aren't restricted, or have restrictions that interact differently that means the user still has alternative means to launch the required application.
That's not what I am seeing...
If you are not seeing the behavior you would expect to see after reading the above, check that there isn't more than one provision that is providing a user with access to the same app. In the case where the user has more than one provision providing them with a particular application, AppsAnywhere will try to take an authoritative approach and choose the provision that gives the user the most freedom.
You will notice that we said AppsAnywhere will try and choose the right provision. This is because there are some scenarios in which it is impossible to choose which is better for the user. If, for example, one provision grants a user off-site access to an app and another provision grants them no off-site access but does permit them to use it on their own device, there's no way to decide which is the "better" choice and so a provision is chosen at random.
As an example, if a member of staff has access to an app as a member of the institution (domain users for example) where the provision restricts all use to on-site only but they also have access through a provision specific to staff members which permits off-site access, then they would expect the least authoritative provision (the one that allows off-site access) to be used when determining if, when and how they can launch the app.
To avoid any unexpected or unwanted behavior that might present itself as a result of AppsAnywhere choosing the wrong provision for a user, you should try to make provisions as exclusive as possible (i.e. avoid situations where a user has access to an app through more than one provision), especially when restrictions are being used. This ensures that the decision as to which provision is used to give a user access to an app is under your control and not decided by AppsAnywhere.