La seguridad en TI es la protección de los sistemas informáticos contra el robo y los daños a su hardware, software o información, así como contra las interrupciones o el uso indebido de los servicios prestados por ellos.
Ver la documentación de InterSystems sobre seguridad.
Buenos días,
Hemos estado indagando de qué manera activar un Servidor para Generar Tokens y un Servidor de Recursos asociado para Validar el Token. Este paso, actualmente lo hemos averiguado con el inestimable apoyo de @Alberto Fuentes de Intersystems.
Hola a todos! Comentamos hoy una entrada de Timothy Leavitt cuyo equipo (Application Services en InterSystems - encargado de desarrollar y mantener muchas de nuestras aplicaciones internas, y proporcionar herramientas y prácticas recomendadas a otras aplicaciones departamentales), durante el último año, se embarcó en un viaje hacia el desarrollo de interfaces de usuario basadas en Angular/REST, para las aplicaciones existentes construidas originalmente con CSP y/o Zen. Esto ha planteado un interesante reto, que os puede resultar familiar a muchos de vosotros: desarrollar nuevas APIs REST para los modelos de datos y la lógica empresarial existentes.
Como parte de este proceso, creamos un nuevo framework para las APIs REST, que ha sido muy útil para nosotros mismos. Ya está disponible en Open Exchange en https://openexchange.intersystems.com/package/apps-rest. Creo que habrá más artículos sobre esto próximamente pero, mientras tanto, hay buenos tutoriales en la documentación del proyecto en GitHub (https://github.com/intersystems/apps-rest).
Como introducción, aquí se encuentran algunos de nuestros objetivos e intenciones de diseño. Todavía no se han realizado todos, ¡pero vamos por buen camino!
Nuestro enfoque REST debería proporcionar el mismo inicio rápido para el desarrollo de aplicaciones que Zen, ya que resuelve problemas comunes y al mismo tiempo proporciona flexibilidad para los casos de uso específicos de las aplicaciones.
La seguridad es una decisión tomada en consecuencia en el momento de diseñar/implementar en vez de una idea de última hora.
La uniformidad del diseño de aplicaciones es una poderosa herramienta para el ecosistema de aplicaciones en una empresa.
Hola desarrolladores,
Estoy seguro de que os habéis encontrado esta situación: necesito autenticar los usuarios - que pueden acceder a la instancia de InterSystems IRIS (for Health) o Health Connect – mediante LDAP (Active Directory u OpenLDAP). En este artículos quiero compartir con vosotros lo sencillo que es la autenticación/integración mediante LDAP. Crearemos una configuración mínima de manera a autenticar los usuarios mediante consulta a OpenLDAP.
¿Cómo podemos comprobar si una contraseña es suficientemente segura, para evitar que sea descifrada? ¿Y cómo podemos crear una contraseña segura?
He desarrollado una herramienta que puede ayudar con esto. Puedes encontrarla en OpenExchange. Instálala con zpm
zpm "install passwords-tool"
Este módulo instalará solo una clase caretdev.Passwords, que contiene algunos métodos que pueden ayudarte.
Para crear una contraseña segura, normalmente es suficiente con usar letras en mayúsculas y minúsculas, números y símbolos especiales, y que tenga al menos 8 caracteres.
¿Te suenan OAuth2 / OpenID Connect pero no estás seguro de cómo se utilizan? ¿Has necesitado implementar alguna vez Single Sign On, servicios web seguros basados en tokens? ¿Has necesitado incorporar autenticación / autorización a tus aplicaciones web o servicios y no sabías por dónde empezar?
¿Que te parecería poder configurar paso a paso un servidor de autorización, un cliente y un servidor de recursos? Aquí tenéis un ejemplo donde se configuran instancias Intersystems IRIS para actuar como cada uno de esos roles de OAuth2.
Autenticación es el proceso de verificar que los usuarios son quienes dicen ser. Autorización es el proceso de otorgar a esos usuarios permisos para acceder a recursos.
OAuth2 es un framework de autorización. OpenID Connect es una extensión de OAuth2 para gestionar autenticación.
En OAuth2, existen diferentes roles:
Además, OAuth2 utiliza scopes o ámbitos como mecanismo para limitar acceso. Un cliente puede solicitar acceso a uno o varios scopes.
Y por último, OAuth2 soporta diferentes tipos de autorizaciones (grant types). Cada tipo de autorización puede tener un flujo diferente y ser más o menos indicada para un determinado tipo de escenario que nos interese montar.
## ¿Qué podrás probar en en el ejemplo?
Probarás dos escenarios. Uno con el tipo de autorización Authorization Code y otro con Client Credentials.
Tendrás 3 instancias de InterSystems IRIS que configurarás para actuar como cada de uno de los diferentes roles.
### Authorization code
Authorization code es un tipo de autorización indicada para escenarios de aplicaciones web / móviles.
En el ejemplo, configurarás lo necesario para tener un cliente web que accede a recursos protegidos utilizando un token de acceso.
Client credentials es otro tipo de autorización, se utiliza típicamente cuando un cliente quiere acceder a recursos directamente en su nombre (y no en el de un usuario).
En el ejemplo, lo utilizarás directamente desde Postman.
¡Hola desarrolladores!
El Concurso de Programación sobre Seguridad ha terminado. ¡Muchas gracias a todos los que habéis participado!
Ya podemos anunciar los ganadores...
Un fuerte aplauso a estos desarrolladores y sus aplicaciones:
¡Hola desarrolladores!
Ya está listo un nuevo concurso de programación de InterSystems:
🏆 Seguridad🏆
Estará activo durante tres semanas: del 15 de noviembre al 5 de diciembre de 2021
Total en premios: $9,450
Página del concurso: https://contest.intersystems.com
.png)
En la Parte 1 empezamos a trabajar en un modelo de seguridad para DeepSee y creamos un tipo de usuario con los privilegios habituales de los usuarios finales. En esta parte, crearemos un segundo tipo de usuario con permiso para editar y crear tablas dinámicas y paneles de control en DeepSee.
Según la documentación (consulta las filas de las tareas "Full access to the Analyzer or Mini Analyzer" (Acceso completo a Analyzer o al Mini Analyzer) y "Creating a new Dashboard" (Cómo crear un nuevo panel de control) que se encuentran en la tabla) es necesario tener permisos de tipo USE en los recursos %DeepSee_AnalyzerEdit y %DeepSee_Portal para conceder acceso completo a Analyzer, y permisos USE en el recurso %DeepSee_PortalEdit para crear y editar los paneles de control. Ten en cuenta que el recurso %DeepSee_Analyzer no es necesario cuando ya se concedió el permiso al recurso %DeepSee_AnalyzerEdit.
Crea un rol DSPowerUser que incluya los siguientes recursos con permisos USE:
| Recurso | Permiso |
|---|---|
| %DeepSee_AnalyzerEdit | USE |
| %DeepSee_Portal | USE |
| %DeepSee_PortalEdit | USE |
| %DB_APP-DATA | RW |
En la página Users (Usuarios) > selecciona la opción Create New User (Crear nuevo usuario), crea un Poweruser con el rol DSUser asignado, como se muestra en la siguiente captura de pantalla:
Abre una ventana de incógnito/privada en tu navegador e inicia sesión como Poweruser. La pestaña Architect de la sección DeepSee aún debería aparecer en color gris. Ve a Analyzer y User Portal, y confirma que Poweruser puede ver, crear y editar tablas dinámicas y paneles de control.
Consejo: Para no tener que entrar en el SMP varias veces con el mismo usuario, haz alguna de las siguientes cosas:
Sugiero utilizar alguno de estos métodos para las aplicaciones web que estén asociadas con el namespace (en nuestro ejemplo /csp/app/) para evitar iniciar sesión cuando se intente acceder a las funcionalidades de DeepSee en ese namespace. Si ves que al usuario se le pide iniciar sesión de nuevo, busca la aplicación web desde la URL o desde el Registro de auditoría, y sigue alguno de los dos métodos indicados anteriormente.
En la Parte 3 crearemos otro tipo de usuario, al que otorgaremos los permisos que generalmente necesita un administrador/desarrollador en Analytics.
Tengo algunos modelos analíticos y numerosos paneles de control, y estoy listo para implementarlos en nuestros usuarios finales y administradores. ¿Cómo configurar DeepSee para que los usuarios no alteren las áreas de los demás y se les restrinja el uso de funciones específicas para los desarrolladores?
¡Hola!
Así es como concedo acceso SQL de usuario a una clase/tabla particular:
GRANT SELECT, UPDATE ON Packacge_X.Table_Y TO UserZ¿Cómo puedo conceder acceso SQL de un determinado usuario a un esquema entero?
Cuando publico mi API, solo está disponible HTTP. ¿Cómo publico mi REST API utilizando HTTPS?
Esto es más una ADVERTENCIA que una pregunta
¡Hola Comunidad!
Hace un par de días, un cliente me comunicó su intención de mejorar su aplicación legacy existente, que usa Servicios Web SOAP, por lo que comparte la misma autorización con su nueva API de aplicación basada en REST. Como su nueva aplicación usa OAuth2, el desafío estaba claro: cómo pasar un token de acceso con una solicitud SOAP al servidor.
Tras Googlear un poco, descubrí que una de las formas posibles de hacer esto era agregar un elemento de encabezado adicional al SOAP envelope y luego asegurarse de que la implementación del Webservice haga lo necesario para validar el token de acceso.
Este artículo, y los dos siguientes de la serie, se conciben como una guía para los usuarios, los desarrolladores o para los administradores de sistemas que necesiten trabajar con la estructura de OAuth 2.0 (conocido también por simplicidad como OAUTH) en aplicaciones que estén basadas en los productos de InterSystems.
¡Hola a tod@s!
Al usar Studio, ODBC o una conexión de terminal a Caché o Ensemble, quizás se haya preguntado cómo podría implementar una conexión segura. Una opción es agregar TLS (también conocido como SSL) a su conexión. Las aplicaciones cliente de Caché (TELNET, ODBC y Studio) todas entienden cómo agregar TLS a la conexión. Tan solo es necesario configurarlas para hacerlo.
Configurar esos clientes es más fácil en la versión 2015.1 y posteriores. A continuación discutiré este nuevo método. Si ya usa el viejo método, este seguirá funcionando, pero le recomiendo considerar pasarse al nuevo.