¿Cómo asegura y mide los servicios web que comparte con sus socios comerciales?

Question

Estoy buscando ideas sobre cómo restringir el acceso y registrar llamadas para una API que estamos entregando para que los socios comerciales interactúen con nuestra aplicación de Atención al cliente. ¿Deberíamos crear nombres de usuario y contraseñas para nuestros socios externos igual que lo haríamos con nuestros propios empleados? ¿Existe algún tipo de capa de complemento para .Net que pueda gestionar las restricciones de acceso y la medición, o tenemos que implementar la nuestra?

¿Qué formatos deberíamos apoyar? ¿JSON es canónico o hay algo nuevo por ahí que necesito saber?

Soy nuevo en el suministro de software como servicio y me gustaría recibir algunos consejos, incluido un proyecto .Net de código abierto que puedo examinar para obtener pistas.

EDITAR: ahora con la frescura bounty!

EDIT: añadir contenido a responder algunas preguntas

Ésta será una API para nuestros socios a utilizar para acceder a nuestras funciones de servicio al cliente, tales como la creación de nuevas cuentas, hacer pagos y otras funcionalidades de gestión de cuentas.

Estoy familiarizado con PostSharp y ya he producido una demostración de tecnología con funciones de registro para llamadas a métodos.

No me interesa encuestar a nuestros socios para qué formatos/protocolos prefieren, ya que uno de los requisitos es la posibilidad de agregar nuevos socios sin la participación de TI. Solo me gustaría algunos consejos sobre las mejores prácticas, para que lo hagamos de la manera "correcta" y puedan conformarse.

Answer 1

Hemos estado usando 3scale. Permite medir y limitar el acceso a su API.

Answer 2

Creo que necesita definir exactamente en qué está pensando.

Software-as-a-service significa que está ofreciendo un software en funcionamiento para que los usuarios trabajen en con sus propios datos mientras usa su software como un instrumento para manipular esos datos. Aquí, los usuarios generalmente no están interesados ​​en los datos que podría ofrecer (es inútil para ellos). SaaS es solo una solución alternativa para ellos. También podrían desarrollar/instalar software para sus necesidades a nivel local, en su red, porque su principal interés está en sus datos y solo necesitan un instrumento para trabajar con él.

En general, con el software como servicio administras a los usuarios a través de sus cuentas. Una cuenta tiene un paquete de características donde define las funciones disponibles, las cotizaciones de los recursos utilizados y los derechos de acceso que definen qué se puede y qué no se puede hacer.

Lo que está describiendo es básicamente un acceso externo a sus datos. Tiene poco en común con el concepto de SaaS. Por ejemplo, los servicios de ubicación GeoIP tienen el mismo problema, dar acceso a su base de datos pero monitorear el uso por usuario (por ejemplo, una cuenta permite 1000 solicitudes de geolocalización para un usuario por mes).

Para entender qué es lo mejor para usted, debe decidir qué tipo de actividades desea realizar a sus socios comerciales.

• ¿Simplemente quieren leer sus datos? Si se trata de un simple consumo de datos, entonces probablemente pueda salirse con la suya con una cuenta de usuario básica con límites de uso. Adivinando su pregunta sobre el formato de datos preferido, supongo que este es su caso.

• ¿Pretenden tomar parte activa en el proceso de atención al cliente y agregar, eliminar, modificar o procesar los datos? En este caso, debe pensar en el diseño de su sistema y diseñarlo (si aún no está allí), un sistema de usuarios, grupos, derechos de acceso y cuotas. Creará cuentas para sus socios comerciales mientras define las actividades permitidas, los límites de uso, etc. Luego deberá actualizar su base de códigos para ver estos parámetros.

En cuanto al formato, creo que es irrelevante para esta discusión y un poco demasiado pronto para pensar. Es posible que desee preguntarles a sus socios qué preferirían.

Answer 3

No tiene muy claro quién es un compañero; o si está protegiendo el acceso a los datos, limitando las llamadas API, o ambos.

Lo que está haciendo es probable que sea muy específico para su negocio. Suponiendo que necesita proteger los datos a los que los servicios proporcionan acceso, necesita autenticar a cada usuario y proteger la capa de transporte. Para el primero, debe tener un nombre de usuario y contraseña, o un token de API exclusivo para los usuarios finales. Esto debe verificarse en cada solicitud. La seguridad del transporte se puede habilitar utilizando SSL si usa HTTP para sus servicios. En general, es más fácil habilitar esto en el nivel del servidor web, no mencionas que estás haciendo un hosting especial de servicios web.

Suponiendo que esta seguridad está en su lugar, debe proporcionar una base para la auditoría que es lo que supongo que quiere decir con llamadas de registro. El nombre de usuario o token de la API le dará una idea sobre quién realiza una llamada, que es fundamental para la auditoría. A continuación, cree una lista de datos que le gustaría ver y una pista de auditoría. Pregúntale a un usuario de negocios si la información registrada puede ayudarte a lidiar con las preguntas que tienes (lo que te impulsa a agregar el registro).

Lo siguiente a considerar es dónde debe ir el código de registro (¿hay un punto central? ¿Utiliza AOP para agregarlo?), Y dónde debe registrarse el seguimiento de auditoría. Hay herramientas como PostSharp que le permiten entretejer el registro a través de su aplicación sin una gran cantidad de modificaciones, pero antes de hacerlo, vea si hay una manera fácil de agregar una función de registro a una ubicación común en su aplicación para 'atrapar' la información que necesita .

Una vez que tiene los datos que necesita para guardarlos en alguna parte. Aquí es donde las cosas pueden ponerse interesantes. Deberá comprender las características de rendimiento de su aplicación y los patrones de uso posibles. En muchas aplicaciones, está bien simplemente iniciar sesión en una base de datos, pero a veces esto será un problema de rendimiento. Iniciar sesión en archivos de texto está bien para algunas personas, pero ¿qué ocurre si los datos deben relacionarse con su base de datos de usuarios? En ese caso, necesita un código para procesar los archivos de registro y los datos de importación.

Antes de dedicar demasiado tiempo a la creación de cualquier código de registro vale la pena mirar NLog, Log4Net, y la Enterprise Library logging block. Estas son herramientas de propósito general que pueden proporcionar una mejor base.

Si necesita hacer cumplir las cuotas de los usuarios, es posible que desee considerar qué tan rápido se puede procesar su registro para determinar cuántas llamadas ha realizado un usuario. Idealmente, cada vez que procese una solicitud entrante, tendrá el estado actual de un usuario a mano para poder devolver una respuesta adecuada. Puede ser un esfuerzo agregar esta funcionalidad a las aplicaciones existentes y proporcionar la 'infraestructura' para soportarla.

El uso de REST, JSON, XML, SOAP, etc. realmente depende de su audiencia. ¿Van a utilizar idiomas como Ruby y Python para llamar a sus servicios, o van a usar .NET? Si van a ser principalmente.A los usuarios de NET, entonces puede que no tenga mucho sentido construir interfaces puramente REST usando JSON, ya que .NET hace que SOAP sea muy fácil. En el otro extremo de la escala, SOAP y XML apestan si está usando JavaScript en el lado del cliente. Solo recuerda que no hay una respuesta correcta sin más información sobre tus usuarios. En general, JSON no es una panacea, y XML no siempre es la peor opción.

actualización

No estoy interesado en topografía nuestros socios para que formatea/protocolos preferirían, ya que uno de los requisitos es la posibilidad de añadir nuevos socios sin la participación de TI . Me gustaría al igual que algunos consejos sobre mejores prácticas, para que lo estemos haciendo de la manera "correcta" y que puedan cumplir.

La opción más flexible es REST y XML. Esto es más ampliamente compatible ya que casi todas las plataformas tienen una pila HTTP. XML es posiblemente más flexible que JSON para representar sus datos. Empezaría aquí y trabajaría en términos de soporte, quizás agregando JSON. Sin embargo, esto no es lo que yo llamaría un enfoque centrado en el cliente. Si esta es una característica central de una plataforma, realmente debería interesarse en lo que quieren sus clientes. Oye, incluso si haces una encuesta rápida hoy, al menos tendrás un punto de partida más razonable. Si conoces a los desarrolladores de los socios, entonces podrías suponer qué preferirían de las herramientas y los idiomas que usan (incluso yendo tan lejos como para mirar sus anuncios de trabajo, podrías darte una idea de si son .NET o Java). comprar, lejos de un enfoque científico).

Answer 4

Para restringir el acceso a sus servicios web, una opción sería implementar un mecanismo de autenticación personalizado basado en encabezados de soap personalizados. No es realmente complicado y no sacrificará la interoperabilidad. Hay un montón de artículo para hacer esto en la web, por ejemplo: Build Secure Web Services With SOAP Headers and Extensions, Authenticate .NET web service with custom SOAP Header, etc.

o podría tener un vistazo a WS-Security y la próxima WS-Autorización para hacer frente a conceptos como la identificación, autenticación y autorización (ver An Overview of the WS-Security Framework). Pero, en realidad, no sé que los servicios web de Microsoft se apilan lo suficiente como para proporcionar valiosos indicadores.

En cuanto al registro de las llamadas, no veo ninguna dificultad en particular. Una vez que se implemente el acceso restringido, descubrirá qué registrar y dónde.

Answer 5

Para la aplicación de las restricciones de acceso

• yo sugeriría que para implementar su propia estrategia. Tenemos un requisito similar anterior y hemos implementado el siguiente enfoque

  • Primer nivel: Nombre de usuario y contraseña deben ser suministrados para cada solicitud.
  • 2do nivel: la clave de sesión (GUID) debe pasarse con cada solicitud.
  • 3er nivel: permisos de nivel de recursos: los códigos de clave específicos deben pasarse para acceder a los recursos. Para lograr esto, debe mantener el conjunto de permisos para cada cliente contra cada resoucres. Esto le permite restringir a los clientes con acceso limitado.

  esto sería algo como esto ..

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

• y sugeriría que utilice los servicios basados ​​en SOAP/XML si el cliente utiliza las tecnologías .Net. REST/JSON es más adecuado para el cliente que usa otras tecnologías. Pero esto depende completamente de las necesidades de sus clientes.