Over the past couple months, I’ve been writing about Logi’s approach to adaptive security and how we integrate new analytics capabilities with existing security models. I’ve gone over authentication, authorization, and integration using Logi’s SecureKey API. I’ve also explained in detail how to integrate adaptive security in a standalone enterprise application as well as in embedded applications.
For my final post in this series, let’s dive deeper into how we manage users in Logi Info. Logi applications are built to preserve all security throughout the dashboards and reports our customers build, so we don’t have to monitor your users or set up permissions every time.
Using SecureKey, we simply leverage your application as an authentication source. You can elect to use any of your existing security Roles and/or Rights available as part of the SecureKey information. Here’s how…
Getting User Roles and Rights
Various security-related elements are used for getting user roles and rights:
If user Roles information is included in the SecureKey request from the Parent application (discussed in my posts on embedded applications), then subsequent report requests will cause that information to be automatically available in the Security element (as shown above left).
If user Roles information is not included in the SecureKey request, it can still be retrieved from a data source using a User Roles element and a data layer (as shown above right). The data returned into the data layer should have either a Role value in the first column of each row or be a single row with one column containing multiple Roles in a comma-delimited list.
If user Rights information is included in the SecureKey request from the Parent application (again, as described previously), then subsequent report requests will cause that information to also be automatically available in the Security element.
If user Rights information is not included in the SecureKey request, it can still be retrieved in several ways, all of which begin with the addition of the User Rights element:
The examples shown here include a User Roles element, but it’s not necessary if Roles are supplied to the Security element via the SecureKey request. These are the three different techniques and elements used to retrieve the Rights:
- Rights From Roles: Builds the list of Rights directly from the Roles values. The Roles and Rights are the same.
- Rights From DataLayer: Builds the list of Rights directly from its child data layer. The data returned should include a Right in the first column of each row, or multiple Rights in a single row in a comma-separated list.
- Right From Role: Defines each Right individually, with one Right From Role element for each right. The element’s ID is the Right value, which corresponds to Security Right ID attributes in elements in report definitions. Right From Role works with user Roles: If a user has a Role that is returned by this element’s child data layer, then he is allowed the Right specified by the element’s ID. The child data layer should retrieve data with a Role value in the first column of each row, or multiple Roles in a single row in a comma-separated list.
These elements may be used in any combination; the Rights retrieved by each are combined together into a comprehensive rights list.
Managing SecureKey Sessions
Now that we’ve authenticated, how does Logi Info protect user sessions and activity?
Logi SecureKey allows you to securely authenticate from the parent application and establish a session in the Logi application. Once a user is finished working with the Logi application, there are several ways to ensure that the session is terminated:
Application Server Time-Out Configuration: Automatic session time-out after a period of inactivity is managed in the web server. The Internet Information Services (IIS) default setting is 20 minutes, but you can adjust this to a shorter interval in order to increase session security. For IIS, this is set in IIS Manager tool or in the web.config or machine.config files. While this, by itself, is not completely secure—it still presents a window of opportunity until the time-out occurs)—it’s a good practice that helps minimize security exposure.
Session Exit Elements: The Action.Exit and Response.Exit elements immediately end the current session and redirect the browser to a URL. In Logi Info, you can initiate this from your parent application by browsing directly to a process task in the Logi app, which runs Response.Exit. Otherwise, both actions are usually initiated by a user action, such as clicking a “Logout” button or link (however, user behavior in this regard may not always be reliable).
Restart Session Attribute: The Security element’s Restart Session attribute causes previous session information to be cleared with each new SecureKey authentication attempt. Turning this feature on is the recommended method to ensure users do not “piggyback” onto a previous user’s session.
Note that all of these scenarios require that your parent application has been designed correctly. The authentication routine in the parent app always needs to include a Logi SecureKey authentication request. It should not, for example, include code that tests to see if a Logi session exists and then skips issuing a new SecureKey request if it does.
Ensuring that there’s a new SecureKey request with each report request will guarantee that other sessions that are not valid (such as those created by using browser bookmarks or shared links) will be rejected and redirected back to the parent app for authentication. It will also ensure that different users on the same machine or browser will also have to authenticate properly (providing that the original user logs out of the parent application session).
Read the rest of the Logi Security Series:
- Integrating Adaptive Security in Embedded Applications – Part 1: How Logi SecureKey Authentication Works
- Integrating Adaptive Security in Embedded Applications – Part 2: How to Configure the Logi and Parent Applications for SecureKey