MVVM на основе веб-сервисов, поддерживающих заявки - PullRequest
1 голос
/ 30 ноября 2009

Я ищу информацию для вызова, с которым я сейчас сталкиваюсь.

Я создал пользовательскую STS WIF, которую я использую для идентификации пользователей, которые хотят вызывать некоторые службы WCF, которые предлагает моя система. Службы WCF используют настраиваемый менеджер авторизации, который определяет, есть ли у вызывающей стороны требуемые требования для вызова данной службы.

Теперь я создаю приложение WPF. поверх этих услуг WCF. Я использую шаблон MVVM, так что модель представления вызывает защищенные сервисы WCF (которые реализуют модель). Проблема, с которой я сталкиваюсь, заключается в том, что я не знаю, может ли текущий пользователь успешно вызывать методы веб-службы, фактически не вызывая их. По сути, я хочу включить / отключить определенные части пользовательского интерфейса, основанные на способности успешно вызывать метод.

Лучшее решение, которое я до сих пор придумал, - это создание службы, которая на основе той же бизнес-логики, что и менеджер политик настраиваемой авторизации, сможет определить, может ли пользователь вызывать данный метод. Теперь метод должен быть передан в эту службу в виде строки или фактически двух строк, ServiceAddress и Method (Action), и на основе этого ввода служба сможет определить, есть ли у текущего пользователя требуемые утверждения для доступа метод. Очевидно, что для того, чтобы это работало, сама служба должна была бы потребовать выданный токен от того же STS и с теми же утверждениями, чтобы выполнить свою работу.

Кто-нибудь из вас делал что-то подобное в прошлом или у вас есть хорошие идеи, как это сделать?

Заранее спасибо,

Klaus

Ответы [ 2 ]

1 голос
/ 01 декабря 2009

Подход, который я выбрал, - это класс, который выполняет проверку ClaimSet для защиты методов, лежащих в основе сервиса. Я использую атрибуты для украшения методов с типом, ресурсом и правильными значениями свойств. Затем в классе проверки есть метод Demand, который выдает исключение, если ClaimSet вызывающей стороны не содержит Claim с этими значениями свойств. Таким образом, перед выполнением любого кода метода сначала вызывается требование проверки заявки. Если метод все еще выполняется после запроса, то вызывающая сторона хороша. В классе проверки также есть функция bool для ответа на тот же вопрос (есть ли у вызывающей стороны соответствующие претензии) без исключения.

Затем я упаковываю класс проверки так, чтобы он был развернут с клиентами, и, пока клиент может также получить ClaimSet вызывающего абонента (который я предоставляю с помощью метода GetClaimSet в службе), тогда у него есть все, что нужно для создания те же оценки, что и модель предметной области. Затем я использую метод bool класса проверки утверждений в методе CanExecute свойств ICommand в моих моделях представлений, чтобы включить / отключить элементы управления и, по сути, не дать пользователю получать исключения авторизации, не позволяя им делать то, что не имеет утверждений для.

Что касается того, как клиент знает, какие требования требуются для каких методов, я полагаю, что я оставляю это на усмотрение разработчика клиента. Вообще на моих проектах это не большая проблема, потому что методы были очень классическими. Таким образом, если метод заключается в добавлении Apple, то требуемая заявка будет интуитивно понятной: Type = Apple, Right = Add.

Не уверен, поможет ли это вашей ситуации, но это хорошо сработало в некоторых проектах, которые я сделал.

1 голос
/ 30 ноября 2009

Это немного зависит от того, какие претензии вам требуются в ваших услугах.

Если для ваших услуг требуется один и тот же набор требований, я бы порекомендовал создать службу, которая не выполняет ничего, кроме проверки заявок, и заранее позвоню. Это позволит вам «предварительно авторизовать» пользователя, в свою очередь включив / отключив соответствующие части пользовательского интерфейса. Когда приходит время звонить на ваши реальные услуги, пользователь может просто позвонить им по своему желанию, и вы уже убедились, что это безопасно.

Если для всех служб требуются разные наборы утверждений, и нет простого способа проверить, что они будут работать заранее, я бы просто позволил пользователю вызвать их и обработать это с помощью обычной обработки исключений. Однако это немного усложнит жизнь, так как вам придется позволить пользователю попробовать (и потерпеть неудачу), а затем отключить.

В противном случае, вы можете сделать что-то похожее на то, что вы предложили - поместить в какую-то форму каталога, который вы можете запросить для конкретного пользователя. В дополнение к простой передаче адреса / метода, было бы лучше разрешить вам просто передать адрес и получить весь набор разрешенных (или запрещенных, в зависимости от того, что меньше) методов. Таким образом, вы можете сократить количество поездок в оба конца только для аутентификации.

...