By default, a deployed on WebSphere Application Server for z/OS code interacts with the operating system and her subsystems using the servant region identity. Also, the identity is taken into account while the JDBC Type 2 driver establishes connections to DB2 or IBM database. The behavior is available to be changed, the OS thread identity may be associated with the Java EE role identity during the EJB or Servlet method invocation. This association means that the caller or security role identity (rather than the servant region identity) is used for z/OS system service requests such as access to files and database management systems.
Let me explain the process. User submits her login and password on the server (let's assume BASIC authorization is configured).
RACF or any other security product checks the login and password pair and if the credentials are correct, lets the application server redirect the user on the requested page.
After successful authentication/authorization, the application server will execute all his activities in z/OS under the caller identity during the current session rather than the servant region identity.
Also, any query to the DB2 subsystem will be executed using the caller identity: see the returned value ('ROOT') by the following query - SELECT CURRENT SQLID FROM SYSIBM.SYSDUMMY1.
There are two options on the Security -> Global Security -> z/OS Security Options page of the WAS Admin Console: Enable application server and z/OS thread identity synchronization, which specifies that application servers can process the SyncToOSThread option (e.g. JOB submissions or log writing) for application components that specify it, and Enable the connection manager RunAs thread identity, which sets the z/OS identity associated with the Java EE identity on the execution thread. Local J2CA connectors may honor the z/OS identity for authentication and authorization when an application requests a connection.
The application server must be restarted for this changes to take effect.
z/OS security product configuration
To perform the identity propagation (either of the SyncToOSThread option or the connection manager), the corresponding server permission must be granted by configuring the SAF product with either of the following profiles:
This allows the server to sync any application identity with the OS identity.
...or...
Additionally, the servant READ access should be granted to the userid in one or more BBO.SYNC.<Run-As user ID> profiles in the SURROGAT class, one for each application identity to be synchronized with the OS identity:
The created profile in the FACILITY class takes effect only after the first server restart, profiles in the SURROGAT class have been available for the application server just after creation of them.
The above configurations are enough for the java thread identity to DB2 thread identity synchronization. Application Sync to z/OS Thread requires configuration in both the application and the application server as well as security product permissions. The WebSphere Application Server developer must configure the application to declare that it wants to run with application Sync to OS Thread.
The Java EE application developer configures the application for individual Enterprise JavaBeans (EJB) or web applications by setting a special env-entry in the deployment descriptor com.ibm.websphere.security.SyncToOSThread={true|false}. The default case in which this deployment descriptor is not specified is equivalent to defining it with a value of false.
Identity propagation is an addition step to better protection your data and applications. Today an organization only secured by the perimeter means absolutely non-protected organization. It is a meaningful security vulnerability to grant access to the information about hundreds or even thousands persons, which use application deployed on an application server, for a 'superuser' the application server is configured to run using identity whom. If the identity propagation is configured, there no reasons for the 'superuser' to be in the system and this security vulnerability is able to be marked as handled. Does security matter for you?
Would you like to give a 'Like'? Please follow me on Twitter!
How it works
Let me explain the process. User submits her login and password on the server (let's assume BASIC authorization is configured).
RACF or any other security product checks the login and password pair and if the credentials are correct, lets the application server redirect the user on the requested page.
After successful authentication/authorization, the application server will execute all his activities in z/OS under the caller identity during the current session rather than the servant region identity.
Also, any query to the DB2 subsystem will be executed using the caller identity: see the returned value ('ROOT') by the following query - SELECT CURRENT SQLID FROM SYSIBM.SYSDUMMY1.
Application server configuration
There are two options on the Security -> Global Security -> z/OS Security Options page of the WAS Admin Console: Enable application server and z/OS thread identity synchronization, which specifies that application servers can process the SyncToOSThread option (e.g. JOB submissions or log writing) for application components that specify it, and Enable the connection manager RunAs thread identity, which sets the z/OS identity associated with the Java EE identity on the execution thread. Local J2CA connectors may honor the z/OS identity for authentication and authorization when an application requests a connection.
The application server must be restarted for this changes to take effect.
z/OS security product configuration
To perform the identity propagation (either of the SyncToOSThread option or the connection manager), the corresponding server permission must be granted by configuring the SAF product with either of the following profiles:
RDEFINE FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE) PERMIT BBO.SYNC.<cell short name>.<cluster short name> CLASS(FACILITY) ID(<CR user ID>) ACC (CONTROL) SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH
This allows the server to sync any application identity with the OS identity.
...or...
RDEFINE FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE) PERMIT BBO.SYNC.<cell short name>.<cluster short name> CLASS(FACILITY) ID(<CR user ID>) ACC(READ) SETROPTS RACLIST(FACILITY) GENERIC(FACILITY) REFRESH
Additionally, the servant READ access should be granted to the userid in one or more BBO.SYNC.<Run-As user ID> profiles in the SURROGAT class, one for each application identity to be synchronized with the OS identity:
RDEFINE SURROGAT BBO.SYNC.<Run-As user ID> UACC(NONE) PERMIT BBO.SYNC.<Run-As user ID> CLASS(SURROGAT) ID(<SR user ID>) ACC(READ) SETROPTS RACLIST(SURROGAT) GENERIC(SURROGAT) REFRESH
The created profile in the FACILITY class takes effect only after the first server restart, profiles in the SURROGAT class have been available for the application server just after creation of them.
Application configuration
The above configurations are enough for the java thread identity to DB2 thread identity synchronization. Application Sync to z/OS Thread requires configuration in both the application and the application server as well as security product permissions. The WebSphere Application Server developer must configure the application to declare that it wants to run with application Sync to OS Thread.
The Java EE application developer configures the application for individual Enterprise JavaBeans (EJB) or web applications by setting a special env-entry in the deployment descriptor com.ibm.websphere.security.SyncToOSThread={true|false}. The default case in which this deployment descriptor is not specified is equivalent to defining it with a value of false.
<env-entry> <env-entry-name>com.ibm.websphere.security.SyncToOSThread</env-entry-name> <env-entry-type>java.lang.Boolean</env-entry-type> <env-entry-value>true</env-entry-value> </env-entry>
Conclusions
Identity propagation is an addition step to better protection your data and applications. Today an organization only secured by the perimeter means absolutely non-protected organization. It is a meaningful security vulnerability to grant access to the information about hundreds or even thousands persons, which use application deployed on an application server, for a 'superuser' the application server is configured to run using identity whom. If the identity propagation is configured, there no reasons for the 'superuser' to be in the system and this security vulnerability is able to be marked as handled. Does security matter for you?
Would you like to give a 'Like'? Please follow me on Twitter!
No comments:
Post a Comment