Designer Security

Documentation home

Ebase Designers are defined in the Ebase Security system. Each user is associated with one or more roles, which are also defined in the Ebase Security system, and define the access level (authorizations) to the various elements within the Ebase Designer.

For information on defining Ebase Designer users, click here.

For information on Ebase Designer security roles and authorizations, click here.

When a form is submitted from the designer, the user definition and associated roles are transferred from the designer to the runtime environment and used to run the form. This is the case, even when runtime security is enabled. Specifically, a logonexit is not invoked when a form is submitted from the designer.

It is possible to maintain designer userids in an external user registry. However, Ebase Designer security roles must be maintained using the supplied Ebase Security system. When userids are held externally, the association with Ebase security roles must also be held externally. Contact Ebase support for more information on this subject.

To access the Ebase Designer, a user must have the following authorization:

Type: DESIGNER

Name: LOGON

Function: Read

At least one additional authorization is required to grant access to the various elements within the Ebase Designer. (See Ebase Security Authorization for more information)

In the supplied system, users are defined using the Ebase security dialog, and are authenticated using the Ebase provided Login Module. If this Login Module is subsequently replaced for some reason, for example to authenticate runtime users against Active Directory, then all user definitions are held externally. However, we still need to associate a user with at least one role in order to grant the authorizations required to access Ebase Designer. This completion of roles associated with a user could be done in one of two ways:

1. By additionally defining each user in the Ebase Security System and adding roles to the user definition or group definitions. To achieve this, the commit() method of the Login Module should call commitSubject() on the Ebase User Manager. However, this technique represents some duplication of user maintenance.

2. By maintaining the association of roles within the external system, e.g. as a comma delimited list. These could be extracted by the Login Module and added to the Subject object as RolePrincipal objects.

As an alternative, it is also possible to direct authentication for runtime users to the Login Module component, but direct authentication for designer users to the User Manager component. In this scenario, designer users can be defined and maintained using the supplied Ebase security system, whereas runtime users are defined externally. This is achieved by specifying the following parameter in UFSSetup.properties:

Ufs.useUserManagerForDesignerAuthentication=true