Create, deploy, and maintain analytic applications that engage users and drive revenue. See a Logi demo

Tips + Tricks

Logi Tutorial: Logi’s Approach to Adaptive Security

By Felipe Blanco | July 12, 2019
Share on LinkedIn Tweet about this on Twitter Share on Facebook

Full Transcript

Logi SecureKey Authentication technology provides integration for applications requiring secure access to a Logi application or embedded Logi components. SecureKey allows for a single sign-on environment but provides enhanced security. User authorization is established and requests are made to a Logi application or embedded components using a special SecureKey.

Logi’s SecureKey authentication is provided for use in scenarios where a Logi application or Logi components are integrated with or embedded into a non-Logi application or parent application, which conducts the initial user authentication.

Sometimes called single sign-on, this arrangement allows users to log in once to the parent application and have their security information propagated to other integrated applications—creating a seamless and secure user experience. This, of course, means that users can’t be authorized to go around the parent application and directly access the other applications.

In the stateless world of web applications, this requires some special mechanisms to ensure security. These mechanisms are provided for Logi applications through our SecureKey technology. The authentication part of SecureKey Authentication refers to the method used by the two applications to verify the validity of requests from users. This is a secondary authentication that occurs separately from the typical standard user login authentication.

There are four steps involved in a typical SecureKey authentication transaction:

  1. In the following example scenario, a Logi application is embedded within its parent application, the parent application initially authenticates the user.
  2. The user successfully logs into the parent application. The exact method it uses to determine that a user is valid is irrelevant to this process, except that user roles and/or rights, if applicable, should be retrieved as part of the authentication.
  3. After the parent application authenticates the user, the page that includes the embedded Logi application loads. The parent application sends the Logi application a request for SecureKey token. The request includes the user id, any roles and/or rights, and the user’s machine’s IP address. When it receives a request for a SecureKey token, the Logi application first verifies that the request came from a valid source. This is done by automatically determining the parent application server IP address and ensuring that it’s in a pre-configured list of approved addresses. If so, the Logi application stores the user information from the requests and returns a unique SecureKey token to the parent application.
  4. The parent application sends that original report requests to the Logi application, appending the SecureKey token. Upon receiving the request, the Logi application automatically determines the client browser IP address and uses it along with this token to authenticate the requests. The client browser IP address is used to verify that each port request for the Logi application is coming from a source that has been authenticated by the parent application. This IP address of the end user computer used to request reports through the parent application. This address is passed in the URL of every request for a SecureKey. If authenticated, a session has started for the user and any roles and rights stored in step two associated with the token are used to authorize access to the correct reports, data, and other resources. The requested report is then generated and returned to the parent application.

When the Logi application session is started for the user, the SecureKey token expires and cannot be used again. Any subsequent reports requested from within the context of the Logi application will use a user’s session to control access to reports, data, and resources. The user is then communicating directly from his or her browser to the Logi application for reports and the parent application is no longer involved as long as the Logi application session persists. If the user’s Logi application session ends and he or she subsequently wants to access reports again, then the process of requesting and using a new SecureKey token will have to be repeated.

Once a SecureKey token is used, it cannot be used again in a different session, and sharing tokens across different clients is impossible as a client browser IP address is referenced within this key when it’s created, making it valid only for the client that made the initial request.

Typically, the information associated with the SecureKey token (including username roles, rights, browser IP address, etc.) is stored as a web server application scope variable. However, if you’re using a clustered server configuration, you can specify a physical folder for temporary storage of SecureKey information as XML files. Using a shared network folder for this purpose allows common access to the SecureKey information by clustered servers. This shared folder is specified in the SecureKey shared folder attribute of the security element in a Logi application setting definition. The SecureKey files created by this option are deleted whenever the automatic temporary cache file cleanup occurs.

Starting with version 12.5, you can save the SecureKey token information and supported databases, including SQL server, Oracle, MySQL and PostgreSQL. The temporary values are stored in a database table, RD SecureKey, and the table is automatically created in the connections database the first time SecureKey is made.

About the Author

Felipe Blanco is a Senior Engineering Manager at Logi Analytics. He has spent time in various engineering and customer solutions roles at Logi, where he's specialized in platform security and UI/UX.

Subscribe to the latest articles, videos, and webinars from Logi.