Introduction to Logi Security
Logi Info includes features, collectively called Logi Security, for securely controlling access to reports and data. This topic provides an explanation of the principles behind Logi Security and details of its implementation.
- About Logi Security
- Authentication - Who is the User?
- Authorization - What is the User Allowed to Do?
- Adding Security to a Logi Application
- Sample Security Applications
A companion topic, Work with Logi Security, provides more detailed information for developers, and another one, Logi Security Scenarios, offers step-by-step guidance for implementing security in different circumstances.
Logi Security provides a flexible mechanism for integrating security features into a Logi application in almost any environment. It lets you can take advantage of the User and Role/Group identification features in Microsoft Windows operating systems, including NT Security and Active Directory domain security, and in other LDAP-based and custom-built security systems.
The Logi Security implementation utilizes the traditional concepts of user authentication and authorization, which are discussed in detail in the following sections.
Security Rights can be assigned to users and then used within a Logi application to restrict users access on these levels:
- Report-level - controls access to report pages.
- Element-level - controls access to portions of reports and report components, and controls report navigation.
- Row-level - controls access to individual data rows.
- Column-level - controls access to individual data columns.
Logi Security gives you, as the developer, complete control over all aspects of report usage.
Working with Logi Add-on Modules
Logi Info Add-on Modules deliver specialized elements and complete applications to users. All are compliant with Logi Security in general and may also have unique constants or security rights that enable access to specific features. Security requirements and settings for add-on modules are discussed in detail in their configuration documents.
Working with LDAP
The Lightweight Directory Access Protocol (LDAP), used for querying hierarchical sets of records, is commonly used to store user and role information. Microsoft's Active Directory, and Oracle's OpenDJ, and Linux OpenLDAP are all examples of LDAP implementations.
In a typical Logi application that uses Logi Security, user credentials entered via a login page are compared against an LDAP server to authenticate the user and retrieve role information. Logi Info includes specialized elements for this purpose, for use with both .NET and Java applications.
Order of Operations
When Logi Security is enabled in a Logi application and a report is browsed, one of the very first things that happens is security processing. Therefore, it's not possible to give users the option to change security-related settings, such as the login domain, at runtime. By the time you could present users with Input controls to select their domain or choose other options, security processing has already occurred.
Working with SSL
Secure Sockets Layer (SSL) is the standard security technology for establishing an encrypted link between a browser and a web server. It ensures that all data passed between the two remains private and complete.
SSL is implemented as a web server configuration and browsers must be able to work with it. Because SSL works with the Transport layer, it does not directly interact with applications. Generally, Logi applications work well with, and are independent of, SSL implementations. No special configuration of a Logi application is required to allow it to work with SSL.
Working with Network Access Servers
Companies that implement central authentication servers using protocols such as TACACS+ and RADIUS will have no difficulty using Logi applications. These protocols, used along with network access servers, generally serve as gatekeepers for access to networks and servers at the communications level. Once access has been granted, the traffic and content from the web servers used to distribute Logi reports operate normally.
In general, security servers that maintain centralized security credentials for users may be accessible as a direct source of credentials for Logi applications. As discussed earlier in the publication, Logi security can work with custom SQL databases that contain security data.
However, the availability of access to these databases, encryption schemes used on the stored data, and other factors make it impossible to state unequivocally that Logi security can access centralized security data in all environments.
Logi Security is compatible with Federal Information Processing Standards (FIPS) security. Specifically, it will work correctly when a user's local or global security policy has its System Cryptography setting configured to "Use FIPS compliant algorithms for encryption, hashing, and signing".
Authentication is the process of identifying the current user, usually the "login" or "logon" process that typically associates a user record with a password. For Logi applications, this can be accomplished by relying on operating system security features, by building a custom Logi-based authentication system, or by letting a parent application handle it. These three authentication methods are discussed in this section.
Once a user is authenticated, a Logi application has access to an internal username that uniquely identifies the current user and drives the authorization process discussed later.
Operating System Authentication
This type of authentication is more commonly used in intranet/extranet environments where web server or domain administrators can easily maintain the list of valid users.
When using Windows OS-based authentication, the IIS web server manages access to a Logi application. IIS determines the user's identity and that identity gets passed into the Logi application.
IIS has a number of authentication options, configurable in the IIS Manager tool (part of which is shown above). Microsoft provides more detailed instructions for using IIS security, but generally you disable Anonymous Authentication and enable Windows Authentication, which validates the user with an account established either on the web server or elsewhere in the network domain. When necessary, the browser displays a login dialog box.
When using Java-based web servers on non-Windows operating systems, the availability of authentication via the web server can be similar but will vary by OS and web server.
Custom Authentication Systems
Custom authentication systems generally provide their own user database that can be queried to authenticate users. Logi Security provides a default login page (rdLogon.aspx for .NET, rdLogon.jsp for Java) that can be used with custom authentication systems. If authentication succeeds, custom systems must pass at least a username into the Logi application.
Custom authentication may work best when operating system-based accounts cannot be easily managed, such as when using a 3rd-party web hosting provider.
Parent Application Authentication
Non-Logi applications that call a Logi report or embed Logi components may do initial user authentication and establish a "single sign-on" relationship with the Logi resources using Logi SecureKey authentication. This technology allows the "parent" application to identify authenticated users to the Logi application/components by passing a security token. This is very useful for developers who want to extend their own applications by integrating Logi analytics and visualization technology into them.
Once we know who the user is, we need to know what he's allowed to do. For more information on Logi SecureKey, see SecureKey Coding Examples.
Authorization determines what an authenticated user is allowed to view and what actions they can perform. Logi Info does this with security Rights, which are granted to the user when he's authenticated.
Rights may be granted to the user individually or because he belongs to a user "Group" that has been granted a set of Rights. Logi Security uses the term "Role" instead of "Group" to designate multiple users.
When the application runs, Rights are represented internally as a string of comma-separated words. For example, "AllUsers, ChicagoStaff, Executives". When Logi Security is in use and debugging is turned on, you can view this string after the user is authenticated in the Debugger Trace Page.
Most of the elements used to create Logi applications are "security-aware": they have a Security Right ID attribute that restricts their use to users with the specified Rights. The example above shows a Data Table Column element configured to only be visible to users who have the HR_Staff security Right.
Using the earlier example, if a user had the Rights "AllUsers, ChicagoStaff, Executives" and the Security Right ID attribute value above was Executives, the user would be able to see the data table column. The attribute will also accept multiple values in a comma-separated list.
This section briefly describes the major elements that are used in a common implementation of Logi application security.
Security is enabled and globally-configured in the _Settings definition. As shown above, the Security element, which becomes the parent of all other security-related elements, has a number of important configuration attributes. These include the Authentication Source, which identifies the type of authentication in use, and Security Enabled, which enables or disables security altogether.
The actual authentication process is dependent on the Security element's Authentication Source attribute settings. When set to AuthNT or SecureKey, authentication takes place outside the application. When set to Standard or AuthSession, authentication takes place inside the application and an Authentication element with a datalayer is used, as shown above, to query a datasource to authenticate the user.
If the security scheme uses Roles (or "Groups"), the application can determine a users' Rights based on their Roles. When AuthNT or SecureKey authentication is used, the application receives the Roles automatically. When Standard or AuthSession is used, the Logi application must retrieve the roles for itself from a datasource, using the User Roles element with a datalayer, as shown above.
If Rights haven't been determined automatically when using AuthNT or SecureKey authentication, they need to be enumerated using a User Rights element. One or more of the three Rights-retrieval elements are then used:
- Rights From Roles - Shown above, builds the list of rights directly from the User Roles values (the Roles and Rights are the same)
- Rights From Datalayer - Retrieves the rights from a datasource using a datalayer
- Right From Role - Defines individual Rights and uses a datalayer to retrieve Roles associated with each Right.
Let's see one more example of Rights-based access restriction in practice:
In order to restrict access to an entire Logi report, its Root element's Security Report Right ID attribute value is set to a Right, as shown above. An "Access Denied" page is returned in lieu of the report page if a user tries to view this page but does not have the matching Right.