Orden de autenticación y autorización

Autenticación se trata de identificar quién está emitiendo el comando y asegurarse de que la persona que llama sea realmente esa persona / sistema. La Autorización se produce necesariamente después, ya que se trata de decidir si el solicitante debidamente autenticado debe poder continuar o no.

En su caso con un comando su , hay dos autenticación / autorización. Supongamos que usted es usuario "bob" y desea hacer un su joe . Va así:

1. El comando su autentica a la persona que llama. La persona que llama es Bob. Esa autenticación es transparente; como usuario humano, no lo ve: el comando su le pregunta al sistema operativo quién es la persona que llama.

2. Ahora que el comando su sabe que la persona que llama es bob, quiere decidir si se debe permitir a bob hacer un su en la identidad joe . Esto es autorización , y ocurre después de la autenticación, como debería ser. Tenga en cuenta que la identidad que se va a autorizar es bob, no joe. En ese momento, no ha habido autenticación para Joe, y la pregunta no es qué puede hacer Joe, sino qué puede hacer Bob.

3. Si el comando su está contento con que Bob le pida que se convierta en joe, entonces continúa. No llega a ese paso en su caso: la autorización previa decidió que bob no puede hacer un su joe . Sin embargo, si lo hubiera permitido, se activaría el segundo procedimiento de autenticación, en el que se debe ingresar la contraseña de joe.

4. Si la segunda autenticación funciona, entonces obtienes un shell que se ejecuta bajo el UID de joe. Cuando ingrese comandos, la autorización se aplicará según esa identidad autenticada: si, dentro del shell obtenido, desea leer un archivo, se usarán los derechos de acceso de lectura para joe .

Para pensar bien acerca de la autenticación y la autorización, siempre recuerde que autorización es para una identidad específica. En el caso de su , el paso de autorización es sobre si bob puede emitir el comando, no joe; por lo tanto, como usa "bob" como entrada, se alimenta de un paso de autenticación anterior para bob con la contraseña de bob, no de la autenticación esperada que usará la contraseña de joe.

¿Cómo puede saber a quién autoriza si no se ha autenticado? La autenticación siempre es lo primero, excepto cuando todos están autorizados o nadie está autorizado.

Editar: parece que ahora tienes dos preguntas :)

1) Lo más probable es que se haya rechazado porque existe una política de control de acceso que impide que su propio UID original realice una operación en el UID del usuario que escribió incorrectamente. Es su propio UID el que lo autenticó (lo que se llama una autoridad ambiental) porque el sistema que realiza las comprobaciones de autenticación confía en su sistema para proporcionar un UID preciso. Su UID no fue autorizado, por lo que se le negó el acceso.

Como nota al margen, algunos protocolos de servidores de autenticación como NIS no tuvieron en cuenta el hecho de que un usuario puede escalar privilegios localmente y su UID local no se puede usar como un token de autenticación. Honestamente, no recuerdo cómo un servidor NIS +, LDAP o Kerberos verificará su identidad antes de verificar si se le permite usar uno de sus recursos (como conectarse a otra cuenta).

2) Algunas personas creen que es una buena idea ofuscar si un intento de autenticación funcionó sirviendo una sesión de honeypot al usuario pobre que escribió mal una ID o contraseña. Estas personas están equivocadas. Si el sistema no le hubiera informado que no estaba autorizado, no se habría dado cuenta de que no había iniciado sesión en la cuenta que esperaba y no habría podido explicar por qué los datos que esperaba encontrar no se encuentran aquí. , o por qué los datos que agregó durante esa sesión no se guardaron realmente en el directorio principal de ese usuario. Estas interrupciones de la interacción son casi fáciles de recuperar, y el beneficio de la seguridad de la ofuscación es muy discutible.

Estoy de acuerdo con las dos respuestas dadas hasta ahora por Thomas Pornin y Steve DL .

La autorización siempre se realiza después de la autenticación, ya que la autorización es el acto de examinar las reclamaciones de un usuario determinado y determinar si el usuario puede hacer lo que está tratando de hacer en base a esas reclamaciones y en función de las políticas de autorización vigentes.

Sin embargo, me gustaría ampliar la definición y afirmar que la autenticación no es necesariamente acerca de su identidad directamente (quién es usted), sino más bien sobre la prueba de la autenticidad de un reclamo que realiza. Un buen ejemplo de eso es cuando voy a comprar alcohol. Al empleado no le importa lo que soy, pero sí me importa mi edad (> 21 en EE. UU., > 20 en Suecia, > 18 en la mayoría de los lugares). Entonces, cuando muestro mi licencia de conducir / tarjeta de identificación / pasaporte, estoy demostrando mi fecha de nacimiento. Los sellos, hologramas y otros mecanismos en la tarjeta demuestran la autenticidad de la reclamación (mi fecha de nacimiento). Pero el empleado no está interesado en mi identidad en sí misma.