En el contexto de los marcos de seguridad, algunos términos comúnmente aparecen sujeto , usuario y principal , de los cuales no he podido encontrar una definición clara y la diferencia entre ellos.
Entonces, ¿qué significan exactamente estos términos y por qué son necesarias estas distinciones de sujeto y principal ?
Respuestas:
Estos son jerárquicos en la forma en que el género, la especie y el individuo son jerárquicos.
Sujeto / Objeto hereda de los mismos términos que se usan en la gramática. En una oración, el sujeto es el actor y el objeto es la cosa sobre la que se actúa. En este sentido, el uso ha existido desde antes de que se inventaran las computadoras. En un contexto de seguridad, un sujeto es cualquier cosa que pueda hacer una solicitud. Como se señaló anteriormente, esto no tiene por qué limitarse a la seguridad de TI, por lo que es una clasificación muy amplia. Lo interesante es que sujeto implica objeto. Sin un objeto, no hay sujeto.
Los directores son lo que los sujetos resuelven. Cuando presenta su tarjeta de crédito, usted es el sujeto y el número de cuenta es el principal. En otros contextos, su identificación de usuario o identificación emitida por el estado es su principal. Pero los principios pueden asociarse con muchos tipos de temas que no son personas. Cuando las aplicaciones solicitan funciones a nivel de sistema, el principal puede ser el firmante de un módulo de código ejecutable firmado, pero incluso en ese caso el usuario que dirige la solicitud sigue siendo el sujeto.
El usuario es más específico que el sujeto o el director, ya que generalmente se refiere a un operador interactivo. Es por eso que tenemos una interfaz gráfica de usuario y no una interfaz principal gráfica. Un usuario es una instancia de sujeto que se resuelve en un principal . Un solo usuario puede resolver cualquier cantidad de principales, pero se espera que cualquier principal resuelva a un único usuario (suponiendo que las personas observen el requisito de no compartir ID). En el ejemplo anterior, el firmante de un módulo de código ejecutable definitivamente no es el usuario, pero es un principal válido. El operador interactivo que intenta cargar el módulo es el usuario.
Como se señaló en los comentarios, incluso las fuentes autorizadas no están de acuerdo con estos términos. Busqué NIST, SANS, IEEE, MITRE y varias fuentes "cuasiautoritarias" como guías de examen de seguridad mientras preparaba esta respuesta. No encontré ninguna fuente única que fuera al menos cuasi autoritaria cubriera los tres términos y todos difirieran significativamente en su uso. Esta es mi opinión sobre cómo se deben usar los términos , pero desde un punto de vista práctico, cuando estás estudiando un manual en medio de la noche, las definiciones tienden a ser lo que el vendedor o el escritor dicen que son. Esperemos que las respuestas aquí proporcionen información suficiente para navegar por las aguas y analizar cualquier documento de seguridad utilizando estos términos.
John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER John (human) SUBJECT > username_1 PRINCIPAL > smartcard_1 USER John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
Echa un vistazo a mi mapa conceptual de autenticación :
Creo que la terminología está tomada de JAAS .
Cuando una aplicación utiliza la autenticación JAAS para autenticar al usuario (u otra entidad como un servicio), se crea un Asunto como resultado. El propósito del Asunto es representar al usuario autenticado. Un Asunto se compone de un conjunto de Directores , donde cada Principal representa una identidad para ese usuario. Por ejemplo, un Sujeto podría tener un nombre Principal ("Susan Smith") y un Número de Seguro Social Principal ("987-65-4321"), distinguiendo así a este Sujeto de otros Sujetos.
El sujeto es la entidad que solicita un servicio. Puede ser un usuario o un proceso. Probablemente por eso se eligió el nombre Asunto en lugar de usuario.
Cuando un sujeto intenta acceder a un servicio, primero debe autenticarse. La autenticación exitosa termina con la carga de los Principios de seguridad para ese Asunto. Por ejemplo, en un sistema de control de acceso basado en roles, un usuario autenticado (conectado) generalmente tendrá dos principios: userId y roleId. En tales sistemas, los privilegios (es decir, quién puede acceder a qué) se especifican tanto para los roles como para los usuarios. Durante la autorización (es decir, verificar si se debe permitir el servicio solicitado), el sistema de seguridad verificará la accesibilidad de los dos principales.
Por lo tanto, desde la perspectiva de la autorización, los principales son las entidades reales para las cuales se permite o no se permite el acceso. El sujeto es solo un usuario / hilo / proceso que contiene algunos principios.
Como T.Rob explicó, Asunto es cualquier entidad que solicita acceso a un objeto. A partir de ese punto, he encontrado un comentario en javax.security.auth. Código de tema que he encontrado MUY útil y fácil de entender:
"Los sujetos pueden tener múltiples identidades. Cada identidad se representa como un Principal dentro del Sujeto. Los principales simplemente unen los nombres a un Sujeto. Por ejemplo, un Sujeto que resulta ser una persona, Alice, podría tener dos Principios: uno que une" Alice Bar ", el nombre en su licencia de conducir, para el Asunto, y otro que une," 999-99-9999 ", el número en su tarjeta de identificación de estudiante, para el Asunto. Ambos Directores se refieren al mismo Asunto aunque cada uno tiene un nombre diferente ".
Espero eso ayude.
Este es el enlace para la explicación a continuación de la documentación de Oracle JAVA SE.
Sujetos, directores, autenticación y credenciales Para autorizar el acceso a los recursos, las aplicaciones primero deben autenticar el origen de la solicitud. El marco JAAS define el término sujeto para representar el origen de una solicitud. Un sujeto puede ser cualquier entidad, como una persona o un servicio. Un sujeto está representado por la clase javax.security.auth.Subject .
La autenticación representa el proceso mediante el cual se verifica la identidad de un sujeto y debe realizarse de manera segura; de lo contrario, un autor puede hacerse pasar por otros para obtener acceso a un sistema. La autenticación generalmente involucra al sujeto que demuestra alguna forma de evidencia para demostrar su identidad. Dicha evidencia puede ser información que solo el sujeto probablemente conocería o tendría (como una contraseña o huella digital), o puede ser información que solo el sujeto podría producir (como datos firmados utilizando una clave privada).
Una vez autenticado, un Asunto se rellena con identidades asociadas o Principales (de tipo java.security.Principal ). Un sujeto puede tener muchos directores. Por ejemplo, una persona puede tener un nombre Principal ("John Doe") y un SSN Principal ("123-45-6789"), que lo distingue de otros Sujetos.
Además de los principales asociados, un sujeto puede poseer atributos relacionados con la seguridad, que se denominan credenciales . Una credencial puede contener información utilizada para autenticar el sujeto a nuevos servicios. Dichas credenciales incluyen contraseñas, tickets Kerberos y certificados de clave pública. Las credenciales también pueden contener datos que permiten al sujeto realizar ciertas actividades. Las claves criptográficas, por ejemplo, representan credenciales que permiten al sujeto firmar o cifrar datos. Las clases de credenciales públicas y privadas no son parte de la API principal de J2SE. Cualquier clase, por lo tanto, puede representar una credencial.
de acuerdo con Rahulmohan, creo que, antes de que se realice la Autenticación, después de que la Autenticación sea principal, en sentido diferente, un sujeto puede tener muchas funciones principales.