Logi SecureKey Authentication

Using Logi SecureKey Authentication

Logi Info, Logi Report
v10 - 23 Mar 2010

The Logi SecureKey authentication method provides improved integration for applications requiring secure access to a Logi application. It supports the "single sign-on" model while enhancing security because user credentials do not need to be exposed in a query string in order to authenticate the user. This document discusses the use of SecureKey authentication; topics include:

How SecureKey Authentication Works
Configuring SecureKey in a Logi Application
Configuring a Parent Application
Working within NAT or Proxy Environments

Logi SecureKey is an extension of Logi Security; if you're unfamiliar with Logi Security, please see Introducing Logi Security.

How SecureKey Authentication Works

In a typical scenario, using SecureKey authentication, there are five steps:

A "Parent" application, which integrates with a Logi application, is responsible for initially authenticating a user (the "single sign-on").

When that user subsequently uses his browser to request something from the Logi application, the Parent application sends the Logi application a request, containing the user ID, desired security roles, and the user's IP address.

The Logi application verifies that the Parent app's server IP address is in the pre-configured list of approved addresses. If so, the Logi application stores the user ID, security role information, and the user's IP address and returns a secure identifying key to the Parent application.

The Parent application then redirects the user's browser request to the Logi application, adding the secure key in the query string of the redirected URL.

The Logi application uses the user's computer's IP address and secure key to authenticate the user's browser request, and the associated security roles to authorize access to the correct data sources and reports. The user ID and role information are stored in Session variables and the requested report is returned to the user.

Within the Logi application, authorization via role-based security is used in the usual way to allow access to reports, datasources, etc. For more information about implementation, see the Authorization section of Introducing Logi Security.

The scenario shown above is but one of several ways the Parent application can be written. There are, for example, different ways to handle subsequent page or report requests from the user, using the now-established session variables rather than sending in the secure key with every request. These decisions, which are circumstances-dependent, are left to the developer. The critical steps are #2 and #3 above, which result in a secure key being generated, session variables being created, and the Logi application being prepared to respond to the user's requests.

Configuring SecureKey in a Logi Application

Implementing SecureKey authentication in a Logi application builds upon existing techniques for implementing Logi Security.

As shown above, a Security element is added to the application's _settings definition. Its attributes are set as follows:

Authentication Source - Select SecureKey from the drop-down list of available values.
Authentication Client Addresses - This is the IP address of the web server/application server making the SecureKey requests (not the end-user's IP address), identified as the "Parent App" in the five images above.

This value can be determined by "pinging" the application server from the web server hosting your Logi applications. If one computer serves both purposes and the Logi apps are being called using localhost in the URL, enter 127.0.0.1 for this value. If multiple servers will be making SecureKey requests, multiple IP addresses can be entered here, separated by commas.
Cache Roles and Rights - Must be set to Session; SecureKey will not work if it's set to False.
SecureKey Shared Folder - Allows SecureKey to be used with clustered configurations in web farms and web gardens. In a single-server configuration, SecureKey keeps SecureKey requests in Application state. With multiple servers, this information is stored in files in the folder named here, which is shared among the web servers. The account used by (or impersonated by) the web application must have network access rights to read, write, and delete files in this folder. Set the SecureKey Shared Folder value to a network path, such as: //mySharedServer/SecureKeyFolder

Old files in the SecureKey shared folder are automatically deleted over time, so do not use this folder to store other files.
Security Enabled - Must be set to True to enable security.

Remember that SecureKey requests from servers whose IP addresses are not in the Authentication Client Addresses list will be rejected.

Next, as shown above, add a UserRoles.SecureKey element beneath the Security element. This causes the Logi application's list of security roles to be populated from the roles in the query string of the request sent by a Parent application.

Rights elements are then added, as usual, beneath the Security element in order to associate roles with rights.

Back to the top

Configuring a Parent Application

The Parent application is responsible for authenticating the user (the "single sign-on") when she first connects. The authentication process should produce a valid user ID and a list of security roles that correspond to roles established in the Logi application.

When the user first requests a report or web page from the Logi application, the Parent application issues a request to the Logi application's Authentication Service using this format:

http://myServer/myLogiApp/rdTemplate/rdGetSecureKey.aspx?Username=bob&Roles=Worker,Manager &ClientBrowserAddress=192.168.4.75

The rdGetSecureKey.aspx service expects these query string values in the URL:

Parameter	Description
Username	The user ID authenticated during the single sign-on process. In your Logi application this can be referenced using @Function.Username~. This token is available for the current users' session and may be referenced in any Logi definition file, including within other child elements of Security, such as Roles and/or Rights.
Roles	A comma-separated list of the security roles for this user, determined during the single sign-on process. If you're implementing the UserRoles.SecureKey element to assign user roles within your Logi App, this comma-separate list becomes your list of Logi user roles. These roles can then be referenced as @Function.UserRoles~ throughout your Logi application session, and may be used to assign UserRights within the security element.
ClientBrowserAddress	The IP address of the requesting user's computer. It's important to understand that, even though this request is being generated by the Parent application, this IP address is not the address of the application server; it is the IP address of the requesting user's computer. The IP address should be determined dynamically; in the example code provided below, for example, the address is determined using Request.UserHostAddress. See the next section of this document for additional information relevant to NAT or proxy environments.

You may also pass additional optional name-value pairs, appended to the end of the query string, to send other information into the Logi application:

http://myServer/myLogiApp/rdTemplate/rdGetSecureKey.aspx?Username=bob&Roles=Worker,Manager &ClientBrowserAddress=192.168.4.75&myParam1=10&myParam2=20

These extra values will be assigned to Session variables and can be accessed in the Logi application using Session tokens. For example, @Session.myParam1~ would equal 10, @Session.myParam2~ would equal 20, etc.

The Authentication Service returns a secure key to the Parent application, which then redirects the user's request to the Logi application URL, passing the secure key as REQUEST or POST parameter. The URL for this redirect will look like:

http://myServer/myLogiApp/rdPage.aspx?rdSecureKey=ABC123456789

The following VB code demonstrates how to call the Authentication Service (rdGetSecureKey.aspx) from an ASP.NET form in a test environment. It assumes the form has two Input Textboxes (txtUsername and txtRoles) and a Submit button (btnLogin).

The code, which executes when the button is clicked, determines the "requesting user's" IP address, assembles and sends the request, gets back the SecureKey, and redirects the user to a Logi application, passing the key.

Protected Sub btnLogin_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles btnLogin.Click
  Dim sLocalInfoUrl As String = "http://localhost/rdweb1" ' the URL from perspective of this web process
  Dim sGetKeyUrl As String = "/rdTemplate/rdGetSecureKey.aspx?Username=" & txtUsername.Text & "&Roles=" &
      txtRoles.Text & "&ClientBrowserAddress=" & Request.UserHostAddress
  Dim webRequest As Net.HttpWebRequest
  Dim webResponse As Net.WebResponse
  webRequest = Net.HttpWebRequest.Create(sLocalInfoUrl & sGetKeyUrl)

  ' run the URL to get the key
  Try
    webResponse = webRequest.GetResponse()
  Catch ex As Exception
    ' if the web server has Basic or NTLM authentication, set the credentials from the current process
    If ex.Message.IndexOf("401") <> -1 Then
      webRequest.Credentials = Net.CredentialCache.DefaultCredentials
      webResponse = webRequest.GetResponse()
    Else
      Throw ex
    End If
  End Try

  Dim sr As New IO.StreamReader(webResponse.GetResponseStream())
  Dim sKey As String = sr.ReadToEnd()
  ' the URL from the perspective of the end user's browser, usually not localhost
  Dim sUsersInfoUrl As String = "http://localhost/rdweb1/rdPage.aspx"
  Response.Redirect(sUsersInfoUrl & "?rdSecureKey=" & sKey)
End Sub

These examples should provide developers with the basic information necessary to implement SecureKey Authentication.

Back to the top

Working within NAT or Proxy Environments

If a company has set up a firewall with NAT'ed addresses or another form of network proxy that flows all traffic to the Logi application through a single IP address or a range of IP addresses, then client IP address checking in SecureKey needs to suppressed because individual user locations will not be unique.

This can be achieved by modifying the parent application's request to the Logi application so that it passes a ClientBrowserAddress value of 0.0.0.0. For example:

http://myServer/myLogiApp/rdTemplate/rdGetSecureKey.aspx?Username=bob&Roles=Worker,Manager &ClientBrowserAddress=0.0.0.0

When using this approach, security can be further enhanced by limiting requests to those from certain parts of the network by using an IP address mask in the web server's security configuration. For IIS, this is accomplished in the IIS Manager's Directory Security tab; for Tomcat this is accomplished by adjusting some of its XML configuration files.

Back to the top