WCF REST - как лучше проектировать для нескольких пользователей, но также ограничивать доступ - PullRequest
Новая
       22

WCF REST - как лучше проектировать для нескольких пользователей, но также ограничивать доступ

0 голосов
/ 31 августа 2011

Я новичок в WCF и REST, поэтому прошу прощения за любые очевидные вопросы.

Я пытаюсь создать RESTful API, который будет использоваться клиентами.API должен быть доступен только для аутентифицированных пользователей, поэтому я считаю, что лучший способ сделать это (из того, что я прочитал за последние пару дней) - это использовать Basic Auth over SSL, что нормально.

Iиметь базовое приложение службы WCF REST в VS2010 для .NET 3.5.- все это было взято непосредственно из http://www.codeproject.com/KB/WCF/BasicAuthWCFRest.aspx

Я пытаюсь понять и разграничить то, как проверять подлинность клиентов, а также ограничивать количество звонков, которые могут совершать клиенты, исходя из того, кто они есть..

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

Я планировал, чтобы оба клиента разместили что-то вроде следующего URL: -

api.mydomain.com / sale /

однако, мне интересно, имеет ли смысл сделать это более понятным: -

api.mydomain.com / clientA / sale / api.mydomain.com/clientB/sale/

... как вы видите, я совершенно потерян!

Кроме того, пример кода, который у меня есть, использует пользовательский MembershipProvider - я понимаю основы членства, но опять же, не знаюесли бы я должениспользовать это каким-либо образом, чтобы ограничить размещение клиентом данных в областях друг друга?

Извините за вафлю - ооочень много вопросов: (

Ответы [ 2 ]

0 голосов
/ 05 сентября 2011

Вот как я это сделал.Я использовал стандартный поставщик членства (но вы также можете сделать то же самое с настраиваемым поставщиком членства) для аутентификации пользователя, но я не позволяю IIS делать это.Я сам аутентифицирую пользователя (как часть REST API) и генерирую токен для этого пользователя, который я сохраняю в базе данных членства и отправляю обратно клиенту.

Для каждого запроса, который клиент делает, он долженотправьте действительный токен.Поскольку токен хранится вместе с идентификатором пользователя, я могу определить, является ли токен действительным и какой пользователь делает запрос.Поэтому я могу определить, разрешен ли запрос, основываясь на моих собственных правилах безопасности.

Если пользователю разрешено делать определенный запрос только для своих данных, вам не нужно отправлять какие-либоидентифицирующая информация, кроме токена.

HTH.

0 голосов
/ 01 сентября 2011

Относительно авторизации (предоставления аутентифицированному использованию доступа к определенным ресурсам) существует несколько способов.

Вы можете ограничить доступ к определенным областям (каталогам / путям URL) через элемент <location> в Интернете.config, а затем с помощью элемента <authorization> разрешить доступ к этим расположениям только определенным пользователям или ролям (группам).Это нормально, если количество мест / пользователей / ролей поддается управлению и не слишком сильно меняется.Например: 

<location path="ProtectedPlaces/Foo">
    <system.web>
        <authorization>
            <allow roles="FooGroup"/>
            <deny users="*"/>
        </authorization> 
    </system.web>
</location>

В качестве альтернативы вы можете использовать подход на основе API, который по сути делает то же самое.Существует множество библиотек, которые могут помочь, включая AzMan ;библиотека авторизации, которая находится в той же «семье», что и поставщик членства в ролях;в корпоративных библиотеках есть еще одна.

Эта статья может оказаться полезной (см. «Шаг 2. Ограничение функциональности на основе ролей пользователя, вошедшего в систему»).

...