Подход, который я выбрал, - это класс, который выполняет проверку ClaimSet для защиты методов, лежащих в основе сервиса. Я использую атрибуты для украшения методов с типом, ресурсом и правильными значениями свойств. Затем в классе проверки есть метод Demand, который выдает исключение, если ClaimSet вызывающей стороны не содержит Claim с этими значениями свойств. Таким образом, перед выполнением любого кода метода сначала вызывается требование проверки заявки. Если метод все еще выполняется после запроса, то вызывающая сторона хороша. В классе проверки также есть функция bool для ответа на тот же вопрос (есть ли у вызывающей стороны соответствующие претензии) без исключения.
Затем я упаковываю класс проверки так, чтобы он был развернут с клиентами, и, пока клиент может также получить ClaimSet вызывающего абонента (который я предоставляю с помощью метода GetClaimSet в службе), тогда у него есть все, что нужно для создания те же оценки, что и модель предметной области. Затем я использую метод bool класса проверки утверждений в методе CanExecute свойств ICommand в моих моделях представлений, чтобы включить / отключить элементы управления и, по сути, не дать пользователю получать исключения авторизации, не позволяя им делать то, что не имеет утверждений для.
Что касается того, как клиент знает, какие требования требуются для каких методов, я полагаю, что я оставляю это на усмотрение разработчика клиента. Вообще на моих проектах это не большая проблема, потому что методы были очень классическими. Таким образом, если метод заключается в добавлении Apple, то требуемая заявка будет интуитивно понятной: Type = Apple, Right = Add.
Не уверен, поможет ли это вашей ситуации, но это хорошо сработало в некоторых проектах, которые я сделал.