As part of my recent series on Logi’s approach to adaptive security, I’ve been outlining best practices for three common use cases when integrating new analytics capabilities with an existing security model:
3. Integrating adaptive security when a Logi report or Logi components are embedded in an existing application
This week, we’ll go into more detail about Use Case 3: Integrating security when Logi components are embedded into another existing application.
In a nutshell, the Parent application authenticates the user by presenting them with a login page or screen. It then passes the authenticated credentials, and any applicable Roles and Rights information, to the Logi application.
Let’s now look at how to configure both the Logi application and your existing Parent application for SecureKey.
Configuring the Logi Application for SecureKey
This scenario is predicated on the installation of related Internet Information Services (IIS) web server features. To use this type of authentication with IIS, your application’s Authentication feature should be configured for Anonymous Authentication.
Then, follow the steps below to configure your Logi Application for this type of authentication.
1. In your Logi application’s _Settings definition, add a Security element, as shown here.
2. Set the Authentication Source attribute value to SecureKey.
3. Set the Authentication Client Addresses attribute value to the IP address of the server hosting the parent application. In the scenario shown here, if both the parent and the Logi applications are on the same server, enter 127.0.0.1. Multiple addresses can be entered as a comma-separated list, if necessary.
4. Set the Security Enabled attribute to True.
5. Add other Roles and Rights elements as may be necessary (not shown).
Next, modify the parent application to interact with the Logi application (see next section).
The tokens @Function.UserName~, @Function.UserRoles~, and @Function.UserRights~ can be used to access the data passed from the parent program.
As a debug tool, it’s very helpful when developing applications using SecureKey to view the information being sent between the parent application and the Logi application. Test applications, for use in a .NET application only, are available for download from Logi DevNet and help by showing the information in a SecureKey exchange.
Configuring the Parent Application for SecureKey
The Parent application is responsible for authenticating the user (the “single sign-on”) when he or she first connects. The authentication process should produce a valid user ID and optional lists of Roles (which correspond to Roles established in the Logi application) and/or Rights.
The ClientBrowserAddress query string value is no longer required.
When the user first requests a report or web page from the Logi application, the Parent application issues a SecureKey request to the Logi application’s authentication service, using this basic format:
The URL may also optionally include a list of Roles and/or Rights, using this format:
The rdGetSecureKey.aspx service called in the URL expects or accepts these standard query string values in the URL: Username (required), ClientBrowserAddress (required), Roles (optional), and Rights (optional).
You may also create your own custom query string variables to send other information into the Logi application:
These extra values will be assigned to session variables in the Logi application and can be accessed using @Session tokens. For example, @Session.myCustomParam1~ would equal 10 and @Session.myCustomParam2~ would equal 120. Remember that theses tokens are case-sensitive and you will need to match the spelling in the query string exactly when using them.
Getting User Roles and Rights
Your Logi application may need to use any security Roles and/or Rights available as part of the SecureKey information. Various security-related elements are used for this purpose:
If user Roles information is included in the SecureKey request from the Parent application (as described in the previous section), 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 above include a User Roles element, but it’s not necessary if Roles are supplied to the Security element via the SecureKey request.
SecureKey Information Storage
Normally, the information associated with a SecureKey (User Name, 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 the clustered servers.
This shared folder is specified in the SecureKey Shared Folder attribute of the Security element, in the Logi application’s _Settings definition. The SecureKey files created by this option are deleted whenever the automatic “temporary cache file clean-up” occurs (this is configurable).