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

Question

Я ищу идеи о том, как ограничить доступ и регистрировать вызовы для API, который мы предоставляем бизнес-партнерам для взаимодействия с нашим приложением Customer Care. Должны ли мы создавать имена пользователей и пароли для наших внешних партнеров так же, как наши собственные сотрудники? Есть ли какой-нибудь слой оснастки для .Net, который может управлять ограничениями доступа и измерениями, или нам нужно накатить свои собственные?

Какие форматы мы должны поддерживать? Является ли JSON каноническим или есть что-то новое, о чем мне нужно знать?

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

РЕДАКТИРОВАТЬ: теперь со свежестью щедрости!

РЕДАКТИРОВАТЬ: добавление контента для ответа на некоторые вопросы

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

Я знаком с PostSharp и уже выпустил демонстрационную версию технологии с функциями ведения журнала для вызовов методов.

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

Answer 1

Мы использовали 3scale . Это позволяет измерять и ограничивать доступ к вашему API.

Answer 2

Вам не очень понятно, кто является партнером; или защищаете ли вы доступ к данным, ограничиваете вызовы 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 магазин - далеко от научного подхода, хотя).

Answer 3

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

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

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

  это было бы что-то вроде этого ..

  if (base.IsUserValid(userObject))
  {
   if (base.ValidateSession("sessionid"))
   {
     if (base.IsUserAuthorizedToAccessResource("resourcekey","ReadorWrite"))
     {             
           //Grant Access
     }
    }
  }
  

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

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