Лучший способ защитить службу REST, к которой будут обращаться мобильные и настольные приложения

Question

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

Но потом я подумал о мобильных приложениях и понял, что Android, например, не сможет передать необходимые учетные данные, поэтому теперь я застрял на том, как его защитить.

Это написано в WCF 4.0, и я подумал о том, чтобы получить учетные данные, затем определить, кто пользователь, а затем проверить, могут ли они использовать запрос GET, и просмотреть данные.

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

Мое настоящее беспокойство касается запроса GET, так как POST будет обрабатываться тем же методом, который я ожидал.

Одним из решений, которое я не считаю хорошим вариантом, было бы заставить их войти в Sharepoint, а затем принимать только перенаправленные запросы от Sharepoint.

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

Итак, как защитить REST-сервис, чтобы знать, кто делает запрос, чтобы можно было принимать решения об авторизации, и он будет работать для смартфонов iphone, android и blackberry.

Answer 1

Мое текущее решение для защиты данных в системе - заставить людей сначала войти в приложение, которое поддерживают службы REST (наша система управления обучением), так как я написал решение SSO, которое выпишетcookie с зашифрованными данными.

Затем служба REST будет искать этот cookie, который исчезает, когда вы закрываете браузер, и мне все равно, если срок действия cookie истек, мне просто нужно имя пользователя из негозатем я могу заглянуть в файл конфигурации, чтобы узнать, разрешено ли этому пользователю использовать эту службу REST.

Это не идеально, и я хочу перенаправить код SSO и получить его.затем отправить человека обратно в службу REST, но это не так просто, как я надеялся.

Мой SSO-код имеет много перенаправлений и перенаправит кого-то на место, которое он выберет в системе управления обучением.просто нужно заставить его работать с другим приложением.

Answer 2

У меня та же проблема, поэтому позвольте мне сообщить вам подробности, а также буду благодарен за отзыв. Поскольку вы используете внутреннюю систему, у вас есть одна дополнительная опция, которую я перечислил.

Мой первый вариант не идеален, да, его можно взломать, но все же - лучше, чем ничего. С каждым запросом вы передаете уникальный идентификатор устройства вместе с хешем. Вы генерируете хеш, используя соль, встроенную в приложение вместе с идентификатором. На сервере вы сопоставляете входящий хеш с генерируемым на сервере хэшем с переданным уникальным идентификатором. Если кто-то «укореняет» свое устройство и достаточно умен, он может найти соль - вы можете скрыть ее дальше, но в конечном итоге она может быть украдена. Кроме того, я храню все запросы по SSL, чтобы просто скрыть процесс. Мое «улучшение» в этом процессе - возвращать новые соли после каждого запроса. Новые устройства получают 1 шанс получить следующую соль или заблокированы ... пока не уверены в этом шаге.

Теперь другой подход состоит в том, чтобы пользователь вводил «соль» или имя пользователя и пароль, которые знал бы только внутренний пользователь - устройство получает токен и затем передает его (по SSL) с каждым запросом. Никто за пределами вашей компании не может получить это, так что это, вероятно, лучше. Я не могу использовать это, так как мое приложение находится в магазине приложений.

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