Autorización JAAS (Java Authentication and Authorization Service)

La arquitectura de seguridad de Java™ 2 utiliza una política de seguridad para especificar los derechos de acceso que se conceden al código en ejecución. Esta arquitectura es centrada en el código. Los permisos se conceden en base a las características del código, incluida la procedencia del código, si tiene firma digital y quién lo firma. La autorización del servicio JAAS (Java Authentication and Authorization Service) aumenta los controles de acceso centrales del código existentes con nuevos controles de acceso centrales de usuario. Se pueden conceder permisos según el código que se está ejecutando y quién lo está ejecutando.

Cuando se utiliza la autenticación JAAS para autenticar a un usuario, se crea un sujeto para representar al usuario autenticado. Un sujeto consta de un conjunto de principales, donde cada principal representa una identidad para dicho usuario. Se pueden conceder permisos en la política para principales específicos. Una vez autenticado el usuario, la aplicación puede asociar el sujeto al contexto de control de acceso actual. Para cada operación posterior con comprobación de seguridad, el tiempo de ejecución Java determinará automáticamente si la política concede los permisos necesarios solo a un principal especificado. Y si es así, la operación estará soportada si el sujeto asociado al contexto de control de acceso contiene sólo el principal designado.

Para asociar un sujeto al contexto de control de acceso actual, se puede llamar al método doAs estático desde la clase de sujeto y se le puede pasar un sujeto autenticado y el método java.security.PrivilegedAction o java.security.PrivilegedExceptionAction. El método doAs asocia el sujeto proporcionado al contexto de control de acceso actual y luego invoca el método run desde la acción. La implementación del método run contiene todo el código que se ha ejecutado como el sujeto especificado. La acción se ejecuta como el sujeto especificado.

En el modelo de programación J2EE (Java 2 Platform, Enterprise Edition) cuando se invoca un método EJB (Enterprise JavaBeans) desde un enterprise bean o un servlet, el método se ejecuta con la identidad del usuario determinada por el valor run-as. La especificación de J2EE Versión 1.4 no indica qué identidad de usuario se ha de utilizar cuando se invoca un enterprise bean desde un bloque de acciones Subject.doAs incluido en el código EJB o en el código del servlet. Una extensión lógica sería utilizar la identidad correcta especificada en el sujeto cuando se invoca el método EJB en el bloque de acciones Subject.doAS.

Permitir que la acción Subject.doAs sobrescriba el valor de identidad run-as es un modo ideal para integrar el modelo de programación JAAS con el entorno de tiempo de ejecución J2EE. No obstante, JAAS introdujo un problema en SDK (Software Development Kit), Java Technology Edition, Versiones 1.3 o posteriores, cuando integró la implementación JAAS Versión 1.0 o posterior con la arquitectura de seguridad de Java 2. Un sujeto asociado al contexto de control de acceso queda cortado mediante una llamada doPrivileged cuando existe una llamada doPrivileged en el bloque de acciones Subject.doAs. Hasta que no se corrija este problema, no habrá un método fiable y eficaz de tiempo de ejecución que garantice el comportamiento correcto de Subject.doAs en el entorno de tiempo de ejecución de J2EE.

El problema se puede describir mejor con el ejemplo siguiente:

Subject.doAs(subject, new java.security.PrivilegedAction() {
     Public Object run() {
              // El sujeto se asocia al contexto de hebra actual
             java.security.AccessController.doPrivileged( new
                     java.security.PrivilegedAction() {
                         public Object run() {
                         // Subject se elimina del contexto
                         // de hebra actual
return null;
             }
       });
              // El sujeto se asocia al contexto de hebra actual
       return null;
  }
});

En el ejemplo de código anterior, el objeto Subject se asocia al contexto de la hebra actual. En el método run de un bloque de acciones doPrivileged, el objeto Subject se suprime del contexto de la hebra. Al salir del bloque doPrivileged, el objeto Subject se restaura en el contexto de la hebra actual. Dado que los bloques doPrivileged se pueden colocar en cualquier lugar de la vía de acceso de ejecución y, de hecho, con bastante frecuencia se instrumentalizan en un entorno de servidor, el comportamiento de tiempo de ejecución de un bloque de acciones doAs resulta difícil de gestionar.

Para solucionar esta dificultad, WebSphere Application Server proporciona una clase de ayudante WSSubject que amplía la autorización JAAS a una invocación del método EJB de J2EE como se ha descrito anteriormente. La clase WSSubject proporciona métodos doAs y doAsPrivileged estáticos que tienen firmas idénticas, como los de la clase de sujeto. El método WSSubject.doAs asocia WSPrincipal, WSCredential y la credencial CORBA con la hebra actualmente en ejecución. Los métodos WSSubject.doAs y WSSubject.doAsPrivileged invocan a continuación los métodos Subject.doAs y Subject.doAsPrivileged correspondientes. La credencial original se restaurará y se asociará a la hebra en ejecución al salir de los métodos WSSubject.doAs y WSSubject.doAsPrivileged.

La clase WSSubject no sustituye al objeto Subject sino que es una clase de ayudante que garantiza un comportamiento de tiempo de ejecución coherente en lo que a la invocación del método EJB se refiere.

El ejemplo siguiente ilustra el comportamiento de tiempo de ejecución del método WSSubject.doAs.

WSSubject.doAs(subject, new java.security.PrivilegedAction() {
     Public Object run() {
              // El sujeto se asocia al contexto de hebra actual
             java.security.AccessController.doPrivileged( new
                     java.security.PrivilegedAction() {
                      public Object run() {
                         // Subject se elimina del contexto de hebra
                         // actual.
return null;
             }
       });
              // El sujeto se asocia al contexto de hebra actual
  return null;
  }
});

Los métodos Subject.doAs y Subject.doAsPrivileged no se integran con el entorno de tiempo de ejecución de J2EE. Los métodos EJB que se invocan dentro de los bloques de acciones Subject.doAs y Subject.doAsPrivileged se ejecutan con la identidad especificada por el valor run-as y no por la identidad del sujeto.
  • El objeto Subject que generan la instancia WSLoginModuleImpl y la instancia WSClientLoginModuleImpl contiene un principal que implementa la interfaz WSPrincipal. Utilizando el método getCredential, para un objeto WSPrincipal, se devuelve un objeto que implementa la interfaz WSCredential. También puede encontrar la instancia del objeto WSCredential en la lista de PublicCredentials de la instancia del sujeto. Recupere el objeto WSCredential de la lista de PublicCredentials en lugar de utilizar el método getCredential.
  • El método getCallerPrincipal para la clase WSSubject devuelve una serie que representa la identidad de seguridad del emisor. El tipo de devolución se diferencia del método getCallerPrincipal de la interfaz EJBContext, que es java.security.Principal.
  • El objeto Subject generado por el módulo DefaultPrincipalMapping de J2C (Java 2 Connector) contiene un principal de recursos y una lista de PasswordCredentials. El principal de recursos representa a la identidad RunAs.
Para obtener más información, consulte el tema sobre la seguridad del conector J2EE.

Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_jaasauthor
File name: rsec_jaasauthor.html