MVVM基于绑定和命令。我理解IsEnabled, IsReadOnly, Visibility和命令CanExecute的绑定可以帮助实现考虑权限的GUI。
然而，我对这种方法有些怀疑。
第一个是需要伴随每个acl逻辑涉及VM的属性与CanRead | CanWrite属性，可以绑定到相应的控件。这意味着绑定需要大量的基础结构编码和XAML类型。解释原因的动态工具提示也可以添加到列表中。
第二个问题是XAML中的错误输入可能会破坏安全性，特别是在读权限方面:控制将保持可见。在大多数(不是全部)情况下，这个问题可以通过业务逻辑层解决，业务逻辑层将属性保留为默认值。但是在"返回"(VM->BL)系统必须只关心允许的属性。
安全性被称为横切关注点。我理解带有拦截的AOP或DI如何帮助实现BL级别的安全性，但是对于在MVVM设计模式的上下文中为GUI实现所有这些东西，我没有什么好主意。
你能分享一下你解决这个问题的经验吗?我所做的是在ViewModel级别创建"字段"的概念。这些字段本质上是"模型的每个属性的属性"的抽象。
例如，"Order"ViewModel中的字段"OrderNumber"将其ReadOnly属性设置为True，而"Account"ViewModel中的字段"Name"将其Required属性设置为True(这更像是业务逻辑的事情，而不是安全性，但无论如何我将这些东西封装在字段中)。
然后我在XAML使用的特殊类中创建了几个附加属性，以及一个特殊的容器("字段编辑器")，在其默认样式中有一堆指向VM中的这些字段的绑定。容器(实际上是一个ContentControl)，当"IsReadOnly"属性被改变时，沿着它的视觉子元素向下走，并将任何TextBoxes, ComboBoxes等设置为只读状态(使用一个巨大的switch语句，因为你可能想要为不同的控件设置不同的属性)。
在我看来，MVVM实际上是解决您刚才解决的问题的好方法。由于MVVM实际上是将UI与代码分离的问题，因此您可以在UI(视图)中真正做"任何"事情，并将所有逻辑放置到模型中。这是类似于控制中的特权和"流"的逻辑。
这样，编码器(通常设计得很差)可以为控件创建逻辑。比如用户什么时候可以保存、删除、打开，以及检查特权和设计师不需要知道的东西。设计人员(通常不能编写好的代码)可以决定用户如何使用控件。比如是否应该通过按钮、上下文菜单或工具栏进行保存。模型/逻辑甚至可以放在设计人员无法看到的自己的DLL中，并且只使用可用的属性。
责任完全由编码器承担，并置于模型中。
对我来说，MVVM不是"基于绑定和命令"。绑定和命令可以很好地用于非mvvm编码方式。但我知道这可能会令人困惑，因为MVVM促使程序员比平时更多地使用命令和绑定。但事实并非如此。这是关于分离逻辑和UI，所以像你解释的问题可能会以最好的方式解决:-)
这至少是我对MVVM、特权和访问控制的看法。
希望我没有完全误解你的问题。根据您的应用程序，这可能有点困难，但我通常使用Prism模块解决这类问题。显然，如果你不使用Prism，这一点帮助也没有。
例如，如果用户只有对某些数据的只读访问，我将在负责的模块中加载一个完全不同的视图。或者，如果它们没有访问权限，该模块就不会加载任何东西。这样，您就可以为只读和读写权限编写单独的视图。
我想你可以走得更远，也换出ViewModels，但我还没有需要这样做。
值得注意的是，我的应用程序使用用户的Windows凭据(以及我们公司AD中的会员角色)进行身份验证，所以这可以在启动时处理。如果您使用不同的登录/凭据系统，则可能需要修改引导程序，以便在加载模块之前等待登录。
根据我的观点和经验，UI永远不应该被用来加强安全性，而仅仅是根据您的业务逻辑(BL)向用户展示他们能做什么和不能做什么。这可以防止XAML错别字导致的漏洞问题，而且，有大约十亿的实用程序和黑客在那里分析/使UI做用户想要它做的事情。
例如:
http://newtipstrik.wordpress.com/2012/02/06/win-enabler/
http://snoopwpf.codeplex.com/
总之，是的，你的UI应该只"意识到"安全上下文，而不是实现它的全部或部分。