IBM Worklight v5.0.5 > WL server administration > Installation

WebSphere Application Server security options


Scenarios

When the user first accesses the app, the app issues an authentication challenge, requiring the user to enter their credentials. If authentication is successful, an LTPA token is obtained. This token is used in subsequent calls.

The LTPA token can also be transmitted to back-end WebSphere applications or services that are in the same security domain as WL server.

You can secure IBM Worklight in a typical WAS runtime environment in either of two ways:

  Option 1 Option 2
BENEFITS Uses the traditional WAS authentication and trust model.

The container enforces all security, so it can use existing third-party SSO products to secure the Java EE container.

Uses the traditional WAS authentication and trust model without the impact of modifying the IBM Worklight Project WAR.

The container enforces all security, so it can use existing third-party SSO products to secure the Java EE container.

The layered authentication of device, application, application instance, and user functions as intended.

Flexibility in configuring specific security settings that are specific to the IBM Worklight runtime environment without being hindered by the underlying container security.

USAGE Suitable for scenarios where the devices can be trusted and access for rogue applications is restricted. Suitable for scenarios where the devices or the apps on the devices cannot be trusted. The multi-step authenticity checking built into IBM Worklight platform ensures denial of service to devices subjected to unauthorized modifications, rogue applications, and unauthorized users.

See also:

  1. Run IBM Worklight in WAS with Java 2 security enabled
  2. Secure Worklight applications and adapters hosted on WebSphere Application Server.


Parent Installation