Integrating Security with Custom Databases for Analytics in Standalone Enterprise Solutions

Logi’s approach to adaptive security means we integrate with whatever security model our customers already have. We typically see three distinct use cases for integrating new analytics capabilities with a preexisting security model:

1. Setting up a standalone analytics solution in an enterprise

2. Setting up a standalone enterprise solution with database integration

3. Embedded in an existing application

In this post, we’ll focus on the second instance: How to configure your web server with Logi applications and integrate your custom database when providing analytics in a separate enterprise application.

In this scenario, your user data is stored in your own database, and the Logi application simply validates the user against it.

>> Are Analytics on Your Product Roadmap? Get Tips for Enhancing Your Application’s Embedded Analytics <<

Standard Authentication

Logi Info includes a default login page that features the login form shown below (its appearance will vary slightly depending on the Theme used). This is the file rdLogon.aspx in your Logi application root folder. You can substitute your own custom login page, as long as you submit user input controls with the same names as those in the default page.

Logon screen for Logi Info application security

After the login page is submitted, the Logi application handles validating the user against your security database.

  • If the user is authenticated, the query should return one row of data and processing continues.
  • If the user is not authenticated, no data should be returned and an error page will be displayed. A default “Access Denied” page is supplied, but you can customize it if desired.

To use this type of authentication with Internet Information Services (IIS) web server features, your application’s Authentication feature should be configured for Anonymous Authentication.

Then, to configure your Logi application for this type of authentication:

1. In your Logi application’s _Settings definition, add a Security element, as shown above.

2. Set the Authentication Source attribute value to Standard.

3. Set the Security Enabled attribute to True.

When using SQL and LDAP authentication methods, there are several subsequent steps you’ll need to take, discussed below.


Authenticating Using an SQL Database

Given the potential for a “SQL injection” attack, we highly recommend that you use a Stored Procedure to authenticate the submitted credentials.

authenticating Logi security using SQL server

1. Add an Authentication element beneath the Security element, as shown above.

2. Add a DataLayer.SP element beneath it and configure it appropriately.

3. Add an SP Parameters and an SP Parameter element, as shown above, beneath the datalayer. Set the SP Parameter’s attributes as shown. The “dt-200” type designation is for VarChar, other types are available in an option list in the attribute. The @Request.rdUsername~ token contains the username value entered in the standard Login page. Custom login pages should take care to preserve the input control IDs in their forms.

4. Add a second SP Parameter element (not shown) and set it similarly for the password, using @Request.rdPassword~. Remember: tokens are case-sensitive!

5. Your authenticating Stored Procedure should look similar to this:

   @username   varchar(20),
   @password   varchar(16)
SELECT User_Name, User_ID FROM UsersTable
   WHERE User_LoginID = LTRIM(RTRIM(@username)) AND User_Password = LTRIM(RTRIM(@password))

Parameters are passed to the SP in the top-to-bottom order of the SP Parameter elements and do not take the parameter IDs into account. Your SP should “receive” and define the parameters in the same order.

6. Add other Roles and Rights elements as may be necessary (not shown).


If the SP returns no data, then the user is not authenticated. A successful authentication will return at least one value, which will be automatically assigned internally to the token @Function.UserName~. If a second value is returned, it will be assigned to @Function.UserID~.


Authenticating Using an LDAP Server

1. Add an Authentication element beneath the Security element, as shown here.

2. Add a DataLayer.LDAP Authentication element beneath the Authentication element.

3. Set its Connection ID attribute value to the ID of a previously configured Connection.LDAP element.

4. Set its Password attribute to the appropriate @Request token from the Login page.

5. Set its User DN Source attribute to an LDAP query that includes the appropriate @Request token and any other LDAP objects and names appropriate to your LDAP server configuration, such as:

   (.NET and Standard LDAP Server)
   SELECT ADsPath FROM 'OU=Staff, DC=example, DC=com' WHERE uid='@Request.rdUserame~' AND objectClass='InetOrgPerson'

   (.NET and Active Directory Server)
   SELECT ADsPath FROM 'DC=myCompanyDomain, DC=local' WHERE 
   SamAccountName= '@Request.rdUserame~' AND objectClass='organizationalPerson'

   (Java and Standard LDAP Server)
   SELECT DN FROM subTreeScope;
   WHERE uid='@Request.rdUserame~' AND objectClass= 'InetOrgPerson'

   (Java and Active Directory Server)
   SELECT CN FROM DC=myCompanyDomain, DC=local WHERE
   SamAccountName='@Request.rdUserame~' AND objectClass='organizationalPerson'


6. Add other Roles and Rights elements as may be necessary (not shown).

The two @Request tokens mentioned above are passed from the Login page to the application, and any custom logon page substituted for the standard logon page must do the same, using the reserved words “rdUsername” and “rdPassword.”

As in the previous scenarios, if the query returns no data, then the user is not authenticated. A successful authentication will return at least one value: the first one will be automatically assigned internally to the token @Function.UserName~ and, if there’s a second one, it will be assigned to @Function.UserID~.

This post was originally published on this site
Comments are closed.