Skip to main content

Adding Security to a Logi Application

  • Updated

Adding Security to a Logi Application

This topic briefly describes the major elements that are used in a common implementation of Logi application security.

Security is enabled and globally-configured in the _Settings definition. As shown above, the Security element, which becomes the parent of all other security-related elements, has a number of important configuration attributes. These include the Authentication Source, which identifies the type of authentication in use, and Security Enabled, which enables or disables security altogether.

The actual authentication process is dependent on the Security element's Authentication Source attribute settings. When set to AuthNT or SecureKey, authentication takes place outside the application. When set to Standard or AuthSession, authentication takes place inside the application and an Authentication element with a datalayer is used, as shown above, to query a datasource to authenticate the user. To call a Process Task during authentication, add a SecurityProcess element as a child of the Security element.

If the security scheme uses Roles (or "Groups"), the application can determine a users' Rights based on their Roles. When AuthNT or SecureKey authentication is used, the application receives the Roles automatically. When Standard or AuthSession is used, the Logi application must retrieve the roles for itself from a datasource, using the User Roles element with a datalayer, as shown above.

If Rights haven't been determined automatically when using AuthNT or SecureKey authentication, they need to be enumerated using a User Rights element. One or more of the three Rights-retrieval elements are then used:

  • Rights From Roles - Shown above, builds the list of rights directly from the User Roles values (the Roles and Rights are the same)
  • Rights From Datalayer - Retrieves the rights from a datasource using a datalayer
  • Right From Role - Defines individual Rights and uses a datalayer to retrieve Roles associated with each Right.

Let's see one more example of Rights-based access restriction in practice:

In order to restrict access to an entire Logi report, its Root element's Security Report Right ID attribute value is set to a Right, as shown above. An "Access Denied" page is returned in lieu of the report page if a user tries to view this page but does not have the matching Right.

Related articles