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:

- 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.
- 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.
- 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.
- 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.
- 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.
<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.
<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>
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
<application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war">
<application-bnd>
<security-role name="anyAppRoleName"/>
</application-bnd>
</application>