IBM WebSphere WASX extension loginType

52 views Asked by At

A stakeholder just requested me to create an XL-Deploy brand new plugin that extends from the official was-plugin-extensions-22.3.1.xldp plugin.

The synthetic.xml file of the official plugin does have a block of code with 8 properties : Synthetic.xml with 8 properties

We copied 3 of those 8 properties to the synthetic.xml of that new plugin: new_synthetic.xml :

  • createScript property contains parameter hidden=true, which will make invisible in XLD's UI, but still accessible within the Python's script. Hidden properties require default values.
  • destroyScript property, also with the parameter hidden=tru
  • createVerb property

We only kept 3 out of the original 8 properties, because the synthetic.xml of the new plugin inherits from was.SystemLoginConfiguration :

inheritance

Although we deleted 4 properties :

  • moduleOrder property , whose kind is integer, specifies the order in which the Java Authentication and Authorization Service (JAAS) login modules are processed
  • className property , by omission, is of the type string. It specifies the class name of the given login module.
  • strategy properties, by omission, is of the type string. It specifies the authentication behavior as authentication proceeds down the list of login modules. A (JAAS) authentication provider supplies the authentication strategy.
  • customProperties properties specifies additional options passed to the login modules during initialization. This process is one of the mechanisms that is used to passed information to login modules.

they are still available on the explorer of XL-Deploy because of inheritance :

inherited_properties_from_the_official_plugin

Regarding the Jython script that we adapted from the official plugin, we do have no idea on how it is invoked (it is neither invoked by means of a Control Task, nor by means of a rules.xml file).

In the original Jython Script of the official plugin, the login is of type "system" and is hardcoded.

Upon request of the stakeholder, we did change this hardcoded login, to accept not only system logins, but also application logins through the Jython script:

changed_login_type

Very intuitively, we also changed the frontend to receive this parameter in the synthetic.xml, by direct input of the user :

user_input_enum_synthetic

Given the Requester's Infrastructure Architecture :

Infrastructure :

  • A Deployment Manager which communicates with the Nodes through the Node Agent

  • 4 Managed Servers which are responsible for serving J2EE requests

    - App_ihm_01
    
    - App_app_01
    
    - App_msg_01
    
    - App_app_02
    

I would like to know if it is possible to infer in which Application Server is the requester attempting to login in through an Applicational login, and what is the expected result

0

There are 0 answers