The scheduler service uses the asynchronous beans deferred start
mechanism to propagate Java™ Platform, Enterprise Edition (Java EE)
service context information to a task when it runs. If you plan to secure
your application using the JAAS security context of the administrative security
mechanism built into WebSphere® Application Server, create each task
with the correct credentials on the thread.
Tasks run with specified security credentials using the following methods:
- Using the Java Authentication and Authorization Service (JAAS)
security context on the thread at the time the task was created. See the Deferred
start and security topic in the Asynchronous beans section of the information
center.
- Using the setAuthenticationAlias method on the TaskInfo object.
- Using a specified security identity on a BeanTaskInfo task TaskHandler
EJB method.
The scheduler service utilizes the asynchronous beans deferred start mechanism
to propagate Java EE service context information to a task when it
runs. The amount of service context information that is propagated is controlled
by the Service Context settings on the WorkManager configuration object that
schedulers reference. For example, security and internationalization service
contexts can be enabled. See the Using asynchronous beans topic for details
on how to configure the Application Server to propagate these service contexts.
Java Authentication and Authorization Service Security
context
If you intend to secure your application using the JAAS security
context of the administrative security mechanism built into WebSphere Application
Server, create each task with the correct credentials on the thread. Once
each task has the correct credentials, you can disable and re-enable administrative
security without causing any security problems. If you do not set the security
context when the scheduler task is created and you later enable security in
the target application, a security exception or error message might display,
such as SECJ0053E. You might also see this error if two or more schedulers
on different servers are accessing the same tables (a clustered or redundant
scheduler) and the security settings are different.
The JAAS security context
is not set if any of the follow conditions are true:
- Administrative security is disabled.
- Security context policies are disabled on the configured WorkManager for
the associated scheduler configuration.
- A credential is not set on the thread. For example, the enterprise bean
or servlet that is used to create the scheduled task is not secured, or the
task was created with a WASScheduler MBean.
If any of the previously mentioned conditions are true when you
create your task and you need to enable security on your application server
or application, you must complete the following steps for each task:
- Find the task using the Scheduler API find or get methods.
- Cancel the task using the Scheduler.cancel() API.
- Recreate the task using the Scheduler.create() method with security enabled.
Submitting a task that was retrieved from the scheduler using the find or
get methods will automatically generate a new task ID.
Security order of precedence
As previously noted,
there are three ways of verifying that a task will run with the correct user
credentials. In addition, each TaskInfo implementation may have its own way
of supplying user information, which may override the standard mechanisms.
If multiple methods are used, refer to the following lists to determine which
security mechanism is going to be employed.
BeanTaskInfo
- TaskHandler security identity set on the process() method of the Enterprise Java Bean
file
- Authentication Alias set with the setAuthenticationAlias method on the
TaskInfo interface
- JAAS security context
MessageTaskInfo
- Authentication Alias set with the setAuthenticationAlias method on the
TaskInfo interface
- The setUsername
and setPassword methods on the MessageTaskInfo interface. See the Deprecated
features article for more information.