Autorización

La autorización del perfil 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 la autenticación responde a la pregunta "¿Es usted quién 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 el perfil 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 el perfil 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 perfil completo 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 el perfil 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.

Icono que indica el tipo de tema Tema de concepto

Términos y condiciones para centros de información | Comentarios


Icono de indicación de fecha y hora Última actualización: 15 de junio de 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_authorization
Nombre de archivo:cwlp_authorization.html