ASP.Net Identity 2.0 Unattended Login

Я использую ASP.Net Identity 2.2 в веб-приложении и отлично работает.ASP.Net Identity 2.0 Unattended Login

Что я хочу сделать, это иметь фоновый сервис, который обращается к веб-приложению, чтобы генерировать миниатюры и/или PDF-файлы некоторых страниц. Эта служба может закончиться запуском в рамках процесса w3wp.exe и запускается с помощью определенных веб-запросов, сделанных пользователями, например. пользователь меняет некоторые настройки, и фоновая служба запускается для восстановления эскизов.

Проблема заключается в том, что фоновая служба может обращаться к страницам без открытия задней двери, которую другие могут использовать для доступа к страницам. В настоящее время у меня есть код, который может скопировать файлы cookie аутентификации из веб-запроса и использовать их для запроса страниц и создания эскизов, но мне нужно иметь возможность сделать это БЕЗ любого существующего подключения для копирования файлов cookie. Он должен иметь возможность получать свои собственные файлы cookie.

Библиотеки, которые я использую для создания файлов PDF/Thumbnails, делают обычные веб-запросы на веб-сервере и используют безгласные браузеры. Мне нужно пройти через веб-сервер, так как на страницах есть много javascript и ajax, поэтому статическим страницам будет сложно сгенерировать.

В идеале он должен использовать «системного» пользователя, которого никто в сети не может войти в систему.

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

Есть ли у кого-нибудь идеи, как это сделать?

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

источник

2016-11-15 Mog0

Вы можете создать другого пользователя для фоновой службы и установить для него роль, например, роль BackgroundServiceApp. Чем вы пишете api, где только эта роль может получить доступ, и в этом api позже ваша служба использует этот userAccount для входа и доступа к своему собственному приложению api, где он может получить информацию о пользователях. Если вы используете Azure, вы можете проверить https://msdn.microsoft.com/en-us/library/azure/dn798668.aspx, также вы можете использовать Azure Queue или Amazon Simple Queue. – Miguel

Отдельный API - это не тот маршрут, который мы хотим принять, поскольку мы пытаемся создать миниатюры/PDF-файлы, которые выглядят так же, как то, что пользователь видит на своем экране, поэтому имеет смысл для доступа к тем же страницам, что и пользователи, и, следовательно, уменьшите дублирование усилий, т.е. просто добавьте дополнительный шаг в конец конвейера вместо того, чтобы иметь два разных конвейера, обращающихся к тем же данным. – Mog0

@ Mog0. В наши дни общий подход заключается в том, чтобы сначала создать API, а затем как ваш пользовательский интерфейс, так и любые другие автоматизированные службы используют один и тот же API для доступа к данным. Таким образом, вы могли бы избежать проблемы дублирования, которую вы только что описали. Очевидно, это не помогает, если вы уже создали свой пользовательский интерфейс, но просто подумал, что я упомянул об этом на будущее. – ADyson

Вы могли бы сделать запуск службы с конкретным пользователем вашего веб-сервиса, а затем позволить этому пользователю доступ к указанным ресурсам вашего веб-сайта, добавив к вашему web.config что-то вроде этого:

<location path="yourdomain/yourresource"> 
    <system.web> 
    <authorization> 
     <allow users="domainname\user" /> 
     <deny users="*" /> 
    </authorization> 
    </system.web> 
</location>

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

источник

2016-11-15 14:56:42 user449689

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

Поэтому я считаю, что вам следует подумать о настройке или жестком кодировании пользователя и пароля в службе, потому что так или иначе ваша служба должна будет пройти аутентификацию против вашего веб-приложения. – user449689

@ Mog0 может быть еще одна идея [эта] (http: // serverfault.com/questions/392606/iis-windows-authentication-except-for-local-machine); у вас может быть веб-сайт, требующий аутентификации, а другой, который не требует его (с ограничением IP), к которому будет доступен только ваш сервис. Но я бы не пошел честно. – user449689

ASP.Net Identity 2.0 Unattended Login

ответ

Смежные вопросы