Over the past few weeks, I’ve been writing about Logi’s approach to adaptive security and the most common use cases we see for integrating new analytics capabilities with an existing security model.
We’ve already discussed the first two use cases
In this post and the next one, we’ll focus on the third instance: Integrating adaptive security when a Logi report or Logi components are embedded in an existing application.
In the embedded scenario, we have three entities:
- The user, who accesses your app and the Logi app
- The Parent application, which is your existing application
- The Logi report or components, which is a fully functional analytics application that embeds in the existing app
With Logi SecureKey, the Parent application authenticates the user and passes the authenticated credentials (and possible the Role and Rights information) to the Logi application. Logi SecureKey technology then verifies that the user request comes from the Parent application and accepts the rights and roles.
The primary benefit of Logi SecureKey Authentication is that it works without having to manage a second set of security or doing any custom development work. For end users, the arrangement allows them 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 means that users can’t be allowed 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. Those mechanisms are provided for Logi applications through our SecureKey technology.
How SecureKey Authentication Works
Let’s look at a typical SecureKey Authentication transaction in depth.
Step 1: As we mentioned, the Parent application is responsible for initially authenticating a user (the “single sign-on”). This occurs when the user logs in to the Parent application. Any applicable user Roles and/or Rights will be retrieved as part of the authentication.
Step 2: The user begins using the application and eventually clicks a link to view a Logi component. The Parent application then sends a request for a “SecureKey” to the Logi app. This request includes the user ID, any user Roles and/or Rights, and the user’s machine IP address (the “client browser IP address”).
Step 3: When it receives the request, the Logi application verifies that it came from a valid source. This is done by automatically determining the Parent application’s server IP address and ensuring that it’s in a list of approved addresses. If so, the Logi application stores the user information and returns a unique SecureKey to the Parent application.
Step 4: The Parent application then redirects the user’s report request to the Logi application, appending the SecureKey to the query string (see “Using the SecureKey” below).
Step 5: Upon receiving the report request, the Logi application automatically determines the client browser IP address and uses it, along with the SecureKey, to authenticate the request.
Once authenticated, a session is started for the user and any Roles and Rights (stored in Step 3) associated with the SecureKey are used to authorize access to the correct reports, data, and other resources. The requested report is then generated and returned to the user.
Managing SecureKey Sessions
When the Logi application session is started for the user, the SecureKey expires and cannot be used again. Any subsequent reports requested from within the context of the Logi application will use the user’s session to control access to reports, data, and resources.
Once a user is finished working with the Logi application, you want to ensure that the SecureKey session is terminated. Related considerations include the application server time-out configuration, session exit elements (Action.Exit and Response.Exit), and the Restart Session attribute.
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 will have to be repeated.
It’s important to note that once a SecureKey is used, it cannot be used again in a different session, and “sharing” keys across clients isn’t possible. This is because the client browser IP address is referenced within the key when it’s created, making it valid only for the client that made the initial request.
Using the SecureKey
When the Logi application’s authentication service returns a SecureKey to the Parent application and redirects the user’s request to the Logi application, it passes the SecureKey as an additional query string parameter. The URL for this redirect will look something like this, using the keywords rdReport and rdSecureKey:
In the next part of this series, we’ll go into further detail on how to configure the Logi and Parent applications for SecureKey Authentication.