Authentication and Authorization Overview

  • updated 5 mths ago

To ensure system security and to provide a tailored user experience, applications perform user authentication and authorization, matching a user to users in a registered users database and applying assigned profiles. LogicNets provides multiple options for authentication and authorization, both internal and external. This document provides the details for using those varied authentication methods.

Several LogicNets system applications require authentication and authorization for specific functionality. These applications include user management, the Designer, and the Knowledge Center. Additionally, customer applications and access to remote resources through web services may require user authentication and authorization.

LogicNets-Supported Authentication

LogicNets v7.4+ supports the Authorization Code flow OAuth 2.0/OpenID Connect (defined in RFC 6749: The OAuth 2.0 Authorization Framework). The LogicNets system provides different components to implement authentication and authorization flows and includes an internal user database for storing user information, passwords, and roles. LogicNets can also use external Identity providers—Azure AD (Office 365), Windows Live, Gmail, Windows Authentication and others—to implement single sign-on (SSO) functionality. Note: For security reasons, this flow should only be used for confidential applications, such as regular web applications, because the exchange includes the application's authentication methods.

LogicNets v8.1+ supports Client Credentials Flow (defined in RFC 6749: OAuth 2.0 Authorization Framework), which is best suited for Machine-to-Machine (M2M) applications--such as CLIs, daemons, or backend services--because the system must authenticate and authorize the application instead of a user.

See the following topics for more detailed information about LogicNets-supported authentication:

Internal User Authentication

With LogicNets' internal user authentication, the system stores the user’s password in the LogicNets admin database. When a user tries to log on, the system compares the password the user enters with the one stored in this admin database. If the user's credentials match, the user is authenticated and the system identifies the user's assigned profile details.

  1. The user starts a LogicNets application.
  2. The LogicNets run-time detects that the application requires authentication and redirects the user to the LogicNets Logon Module.
  3. The user fills in the user credentials and the LogicNets Logon module validates these.
  4. When the credentials are correct the user is redirected back to the LogicNets application.
  5. The run-time requests for the user access token
  6. The logon module returns the user access token. This token contains information about the user such as the user-name, email address, company name etc. and it contains information about the user roles and groups. The run-time checks whether the application roles are listed in the user access token. 

External User Authentication

LogicNets applications can also use external user authentication. When this is used, the application does not access internal authentication methods but instead redirects the browser to an external identity provider logon screen. The external identity provider checks the user’s username and password, and if the user has entered the correct credentials the identify provider sends an authorization token with the user’s identity back to the LogicNets system. The LogicNets system verifies that this user is authorized to use this application.

Using external user authentication has distinct advantages, including the following:

  • The user does not need to remember multiple passwords and usernames.
  • Password expiry handling is managed by the external identity provider.
  • Support for multi-pass authentication is possible.
  • LogicNets does not need to store and secure passwords.

Authorization can be either role-based or user-based. When an application uses role-based authorization the LogicNets system only maintains a list of authorized user roles. If a logged on user has a role that matches one of the listed roles the system will allow the user to use the application. The advantage of this approach is that no specific user information is managed in the application.

If the external identity provider does not support role-based authentication the system must implement user-based authorization instead. For this type of authorization, the system maintains a list of authorized users, and when a user logs on the system looks up the user's id in the list of authorized users. If the system finds a match it grants the user access to the application.

The following sequence chart illustrates the high-level concept of using external identity providers.

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 2 yrs agoLast active
  • 132Views
  • 4 Following