Как Вы защищаете и измеряете веб-сервисы, которые Вы совместно используете со своими деловыми партнерами?

Я думаю, вам нужно определить, о чем именно вы думаете.

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

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

То, что вы описываете, в основном представляет собой внешний доступ к вашему данные . Это имеет мало общего с концепцией SaaS. Например, у служб определения местоположения GeoIP есть та же проблема: предоставить доступ к своей базе данных, но контролировать использование для каждого пользователя (например, учетная запись позволяет пользователю 1000 запросов геолокации в месяц).

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

• Они просто хотят прочитать ваши данные? Если речь идет о простом потреблении данных, то вам, вероятно, удастся создать базовую учетную запись пользователя с ограничениями на использование. Судя по вашему вопросу о предпочтительном формате данных, я полагаю, что это ваш случай.

• Намерены ли они принимать активное участие в процессе обслуживания клиентов и добавлять, удалять, изменять или иным образом обрабатывать данные? В этом случае вам необходимо продумать дизайн вашей системы и разработать (если ее еще нет) систему пользователей, групп, прав доступа и квот. Вы будете создавать учетные записи для своих деловых партнеров, определяя разрешенные действия, лимиты использования и т. Д. Затем вам нужно будет обновить базу кода, чтобы следить за этими параметрами.

Что касается формата, я думаю, что он не имеет отношения к этому обсуждению и немного рано думать об этом.

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

] Или вы можете взглянуть на WS-Security и предстоящую WS-Authorization, чтобы иметь дело с такими понятиями, как идентификация, аутентификация и авторизация (см. Обзор WS-Security Framework ). Но на самом деле я недостаточно хорошо знаю стек веб-служб Microsoft, чтобы предоставить ценные указатели.

Что касается регистрации вызовов, я не вижу особых трудностей. Как только будет реализован ограниченный доступ, вы узнаете, что и где регистрировать.

Для реализации ограничений доступа

• я предлагаю вам реализовать ваша собственная стратегия. У нас есть подобное требование ранее, и мы реализовали следующий подход

  • Первый уровень: Имя пользователя и пароль должны быть предоставлены для каждого запроса.
  • Второй уровень: Ключ сеанса (GUID) должен передаваться с каждым запрос.
  • 3-й уровень: Разрешения на уровне ресурсов - для доступа к ресурсам необходимо передать определенные коды ключей. Для этого вам необходимо поддерживать набор разрешений для каждого клиента в отношении каждого ресурса. Это позволяет вам ограничивать клиентов с ограниченным доступом.

  это будет примерно так ..

   if (base.IsUserValid (userObject))
  {
   если (base.ValidateSession ("sessionid"))
   {
   если (base.IsUserAuthorizedToAccessResource ("ключ ресурса", "ReadorWrite"))
   { 
   //Предоставление доступа
   }
   }
  }
  

• И я бы посоветовал вам использовать сервисы на основе SOAP / XML, если заказчик использует технологии .Net. REST / JSON лучше всего подходит для клиентов, использующих другие технологии. Но это полностью зависит от потребностей ваших клиентов.

Вы не очень понимаете, кто является партнером; или защищаете ли вы доступ к данным, ограничиваете вызовы API или и то, и другое.

То, что вы делаете, скорее всего, будет очень специфичным для вашего бизнеса. Предполагая, что вам необходимо защитить данные, к которым сервисы предоставляют доступ, вам необходимо аутентифицировать каждого пользователя и защитить транспортный уровень. Для первого вам необходимо иметь имя пользователя и пароль или уникальный токен API для конечных пользователей. Это следует проверять при каждом запросе. Транспортную безопасность можно включить с помощью SSL, если вы используете HTTP для своих служб. Как правило, проще всего включить это на уровне веб-сервера, вы не должны упоминать, что выполняете какой-либо специальный хостинг веб-сервисов.

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

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

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

Прежде чем тратить слишком много времени на построение любого кода журналирования, стоит взглянуть на NLog , Log4Net и блок журналов Enterprise Library . Это инструменты общего назначения, которые могут обеспечить лучшую основу.

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

Использовать ли REST, JSON, XML, SOAP и т. Д. Действительно зависит от вашей аудитории. Собираются ли они использовать такие языки, как Ruby и Python, для вызова ваших услуг, или они будут использовать .NET? Если они будут в основном пользователями .NET, то, возможно, не имеет большого смысла создавать чисто REST-интерфейсы с использованием JSON, поскольку .NET делает SOAP очень простым. На другом конце шкалы SOAP и XML - отстой, если вы используете JavaScript на стороне клиента. Просто помните, что нет правильного ответа без дополнительной информации о ваших пользователях. Как правило, JSON - не панацея, а XML - не всегда худший вариант.

Обновление

Мне не интересно изучать наши партнеры, для которых форматы / протоколы они бы предпочли, так как один из требования - это возможность добавлять новые партнеры без участия ИТ. Я бы просто как несколько советов по передовой практике, так что мы делаем это "правильно" и они могут соответствовать.

Наиболее гибким вариантом, вероятно, будут REST и XML. Это наиболее широко поддерживается, поскольку почти все платформы имеют стек HTTP. XML, возможно, более гибкий, чем JSON, для представления ваших данных. Я бы начал здесь и вернусь к поддержке, возможно, добавив JSON. Однако это не то, что я бы назвал подходом, ориентированным на клиента. Если это ключевая особенность платформы, вам действительно стоит интересоваться тем, чего хотят ваши клиенты. Эй, даже если вы проведете сегодня быстрый опрос, по крайней мере, у вас будет более разумная отправная точка. Если вы знаете каких-либо разработчиков у партнеров, вы можете догадаться, что они предпочли бы, исходя из инструментов и языков, которые они используют (даже если вы посмотрите их объявления о вакансиях, это может дать вам некоторое представление о том, являются ли они .NET или Java. магазин - правда, далекий от научного подхода)