Autorización

La autorización de Liberty determina si un usuario tiene acceso a un rol determinado en el sistema.

La autorización especifica los derechos de acceso a los recursos. Normalmente, va después de una autenticación que confirma una identidad. Mientras que la autenticación responde a la pregunta: ¿Es usted quien afirma ser?; la autorización responde a la pregunta "¿Tiene permiso para hacer lo que está intentando hacer?".

Autorización para funciones administrativas

Cuando una entidad intenta acceder a un recurso, el servicio de autorización determina si dicha entidad tiene los derechos necesarios para acceder al recurso. Este concepto es cierto si una entidad está accediendo a una aplicación o realizando funciones administrativas. La principal diferencia entre autorizar el acceso a una aplicación y el acceso a una función administrativa radica en cómo los usuarios están correlacionados con roles. Para la autorización de las aplicaciones, utilice el elemento application-bnd del archivo server.xml o el archivo ibm-application-bnd.xml/xmi para correlacionar los usuarios con los roles. Para la autorización de las funciones administrativas, utilice el elemento administrator-role del archivo server.xml para correlacionar los usuarios con el rol de administrador. Para obtener más información sobre la seguridad administrativa, consulte Conexión con Liberty utilizando JMX.

Autorización para aplicaciones

El siguiente diagrama describe cómo funciona la autorización para las aplicaciones:

Figura 1. Visión general del proceso de autorización El servicio de autorización comprueba las correlaciones de roles con usuarios en los archivos de configuración de la aplicación y el servidor y, a continuación, otorga o rechaza la solicitud de acceso.
  1. Una autorización se realiza cuando una entidad intenta acceder a un recurso de una aplicación a la que da servicio Liberty. El contenedor web llama al servicio de autorización para determinar si un usuario tiene permiso para acceder a un determinado recurso, en base a un conjunto de uno o más roles necesarios. Los roles necesarios están determinados por los elementos auth-constraint del descriptor de despliegue y las anotaciones @ServletSecurity.
  2. El servicio de autorización determina con qué objetos se correlaciona el rol necesario. Este paso se realiza procesando las correlaciones definidas en el archivo ibm-application-bnd.xmi o ibm-application-bnd.xml y el elemento application-bnd del archivo server.xml. Las correlaciones de estas dos fuentes se fusionan. Si el mismo rol está presente en ambos orígenes, sólo se utiliza la correlación de roles del archivo server.xml. La ventaja de utilizar el archivo server.xml para la correlación de roles con usuarios es que la aplicación no necesita estar empaquetada en un archivo EAR y es más fácil de actualizar. De forma alternativa, utilizar el archivo ibm-application-bnd.xmi/xml hace que la aplicación se pueda mover a otros servidores y otros servidores del WebSphere Application Server tradicional que no soportan el archivo server.xml.
  3. Si el rol necesario está correlacionado con el sujeto especial EVERYONE, el servicio de autorización responde inmediatamente para permitir el acceso a cualquiera. Si el rol está correlacionado con el sujeto especial ALL_AUTHENTICATED_USERS y el usuario está autenticado, el servicio otorga acceso al usuario. Si ninguna de estas condiciones se cumplen, entonces el servicio de autorización determina qué usuarios y grupos se correlacionan con el rol necesario. El servicio de autorización otorga acceso al recurso si el usuario está correlacionado con el rol necesario o si el usuario forma parte de un grupo que se correlaciona con el rol.
  4. El servicio de autorización devuelve un resultado al contenedor web para indicar si se otorga o deniega el acceso al usuario.

Sujetos especiales

Cuando correlaciona entidades con roles, puede correlacionar un sujeto especial, en lugar de un usuario o grupo específico. Un sujeto especial es una extensión del concepto de un sujeto. Un sujeto especial puede representar un grupo de usuarios que entran dentro de una categoría específica.

Están disponibles los dos tipos de sujetos especiales siguientes:
  • EVERYONE: representa cualquier entidad en el sistema, lo que significa que no hay ninguna seguridad disponible porque todo el mundo tiene el acceso permitido y no se le solicitará que especifique las credenciales.
  • ALL_AUTHENTICATED_USERS: representa cualquier entidad que se autentica correctamente en el servidor.
Para correlacionar un sujeto especial con un usuario, actualice el archivo ibm-application-bnd.xmi/xml o el archivo server.xml, donde application-bnd se encuentra bajo el elemento application. En este ejemplo, el rol denominado AllAuthenticated se correlaciona con el sujeto especial ALL_AUTHENTICATED_USERS:
    <application-bnd>
           <security-role name="AllAuthenticated">
               <special-subject type="ALL_AUTHENTICATED_USERS"/>
           </security-role>
       </application-bnd>

Consulte Configuración de la autorización para aplicaciones en Liberty.

ID de acceso y autorización

Cuando se autoriza un usuario o grupo, el servidor necesita un modo de identificar de forma exclusiva dicho usuario o grupo. El ID exclusivo del usuario y grupo sirve para este fin y se utilizan para crear la configuración de autorización. Estos ID los determina la implementación del registro de usuario: el ID de usuario exclusivo es el valor de getUniqueUserId() y el ID de grupo exclusivo es el valor de getUniqueGroupId(). También puede optar por especificar explícitamente un ID de acceso para el usuario o grupo en la configuración de autorización. Estos ID de acceso explícito se utilizan en lugar de los valores que devuelve la implementación del registro de usuarios. Para especificar un ID de acceso en el archivo ibm-application-bnd.xml/xmi o el archivo server.xml, donde application-bnd se encuentra bajo el elemento application, utilice el atributo access-id para el elemento user o group.

En este ejemplo, un ID de acceso se especifica para el usuario Bob y el grupo developers:
    <application-bnd>
           <security-role name="Employee">
               <user name="Bob" access-id="user:MyRealm/Bob"/>
               <group name="developers" access-id="group:myRealm/developers"/>
           </security-role>
    </application-bnd>
Nota: El atributo access-id se utiliza para la comprobación de autorización. Si no se especifica, se determina a partir del registro que se ha configurado utilizando el nombre de usuario o de grupo. Sin embargo, debe especificar el atributo access-id como se muestra en el ejemplo cuando los usuarios o grupos no pertenecen al registro activo. Por ejemplo, al utilizar un inicio de sesión programático.

OAuth

OAuth es un estándar abierto para la autorización delegada. La infraestructura de autorización OAuth permite al usuario otorgar a una aplicación de terceros acceso a su información almacenada con otro servicio HTTP sin compartir sus permisos de acceso ni todo el conjunto de sus datos. Si desea más información sobre cómo utilizar OAuth para la autorización en Liberty, consulte la documentación de OAuth.

Autorización para aplicaciones cuando no se proporciona un enlace de correlación de roles

Cuando no se proporciona la información de enlace de correlación de roles para una aplicación protegida, el motor de autorización predeterminado toma el nombre del rol que está protegiendo el recurso como el nombre de grupo asociado a dicho rol. Así, por ejemplo, si el nombre del rol es gestor, un usuario que pertenece a un grupo de gestores tiene acceso a dicho recurso. Esto sólo se aplica cuando no se especifica ninguna información de enlace de aplicación, en server.xml o el archivo de enlace de aplicación, para la aplicación: por ejemplo, al añadir este enlace se inhabilita el rol de seguridad para el enlace de grupo:
<application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war">
      <application-bnd>
	     <security-role name="anyAppRoleName"/>
      </application-bnd>
</application>
Nota: Para que una autorización sea satisfactoria con un nombre de grupo en el registro de usuarios, el nombre de rol debe coincidir con el nombre completo o exclusivo del grupo en el registro que se ha configurado y no con el nombre abreviado. Por ejemplo, si el nombre abreviado del grupo es swGroup, pero el nombre completo o exclusivo en el registro de usuarios es CN=swGroup,o=company,c=us, debe especificar CN=swGroup,o=company,c=us como nombre de rol para que la autorización sea satisfactoria.

Icono que indica el tipo de tema Tema de concepto



Icono de indicación de fecha y hora Última actualización: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-libcore-mp&topic=cwlp_authorization
Nombre de archivo:cwlp_authorization.html