Защита веб-службы 'pass through'

Question

В настоящее время я назначен на проект, который включает в себя реализацию back-end для приложения, которое будет разработано на более позднем этапе. Приложение будет запрашивать конфиденциальную (личную) информацию с другой платформы в первой (прототипе) версии (доступной для каждой службы SOAP). В будущем мы добавим больше платформ. Поэтому следующая мысль пришла:

APP <---> NEW WEB SERVICE <---> SOAP SERVICE (with the actual data) 

Мы возлагаем новый WebService между приложением и службой SOAP, поскольку служба SOAP строится на внешней стороне (на самом деле не взаимодействующей). Кроме того, из-за следующей ситуации, которая может возникнуть, в том случае, если мы будем иметь больше источников для питания данные:

APP <---> NEW WEB SERVICE <---> SOAP SERVICE (with the actual data) 
          <---> WEB SERVICE #2 
          <---> WEB SERVICE #3 

Поскольку веб-среде, где пользователь может войти в уже существует, и наш менеджер хочет иметь одна учетная запись для приложения и веб-среды, аутентификация для пользователей должна ВСЕГДА выполняться службой SOAP. Это усложняет аспект аутентификации и безопасности в новой веб-службе.

Вопрос возникает, если это означает, что «новый веб-сервис» - это не более чем «проход» или «пересылка»? Но как я должен защищать этот «новый веб-сервис»? Аутентификация и сеансы должны обрабатываться существующей службой SOAP.

Если «новый веб-сервис» предоставляет аутентификацию и такие решения, как: Oauth или ASP.NET Identity. Я провел исследования по этим вариантам и пришел к выводу, что они не применяются в этом контексте.

Мой вопрос: Как получить максимальную отдачу от доступных параметров безопасности для этой новой (пересылающей) веб-службы? Если я даже должен добавить дополнительный уровень безопасности или нет.

я придумал следующее, не уверен, если это будет правильный подход:

• Использование TLS версии 1.2 (очевидно);
• Создайте ключ и секрет api для каждого пользователя;
• Шифровать данные для входа пользователя (имя пользователя, пароль) с асимметричным алгоритмом шифрования.

Answer 1

Короткий ответ на ваш вопрос: NO. Выполнение проверки уровня пользователя из веб-службы может замедлить работу всей системы, и, что более важно, она не добавляет никакого значения. Вместо этого вам необходимо убедиться в том, что веб-служба защищена и не может быть доступна неавторизованными сторонами. Для этого вы можете использовать сертификаты, WSS, SSL, брандмауэры и т. Д.

Предположим, что этот веб-сервис используется в школе для публикации результатов экзамена. Поэтому, очевидно, ученики не должны иметь к нему доступ. Таким образом, вы должны контролировать это на уровне своего приложения, а не на уровне веб-службы. Вы можете позволить студентам отправить сообщение на WS, а затем получить ответ от WS, в котором говорится: «Вы не авторизованы для этого». Но он будет потреблять ваши ресурсы без необходимости. Это также замедлит работу вашей системы.

2-й сценарий, который вы упомянули, действителен. Хорошая практика - иметь средний слой, чтобы вы могли обслуживать несколько версий внешнего веб-сервиса без изменения основного приложения. Если внешнее приложение не очень надежное, вы также можете обработать проблемы надежности изящно, используя этот средний уровень. Например, предположим, что внешняя служба используется для ledger posting.Это означает, что ваше приложение будет отправлять любую транзакцию только один раз. Что вы делаете, если это не удается? У вас может быть механизм повтора в вашем среднем слое. Точно так же средний уровень может фактически повысить ценность вашей системы, если она разработана тщательно.