Authentication Methods
Authentication and Permissions
To ensure secure access to the portal's data via OData services, user authentication is performed using the portal server's login methods. The following section describes the types of authentication methods that are supported and how to configure them. You can define either a global method for all services or a specific method for each service. A user's data group permissions are checked by the Intrexx Portal Server for OData requests, just as they are in the portal. If a user does not have sufficient permissions to read or modify records, the OData service responds with either an empty result set or a permission error.
Intrexx Authentication
With Intrexx authentication, users log in using a username and password, and the password is transmitted in encrypted form using a challenge key provided by the server. This is the recommended method for accessing an OData service in another Intrexx portal from an Intrexx portal.
Plain-text authentication
Plain-text authentication corresponds to the HTTP Basic authentication method. This allows users to log in to the service directly in their browser. However, the password is transmitted in plain text, which is why this method should only be used when SSL encryption is enabled.
Combined Intrexx and Plain Text Authentication
As a rule, OData services use a combination of Intrexx and plain-text authentication. First, the system attempts to log in the client using Intrexx authentication. If this fails, plain-text authentication is performed. If this also results in an error, the client's request will be denied.
Integrated Windows Authentication
With Integrated Windows Authentication, users are identified via Active Directory/LDAP and logged in using the Kerberos protocol. This makes it possible to implement single sign-on in Windows environments. This method is available only with Microsoft Windows Server and in a domain environment. Once integrated Windows authentication is enabled for a portal, OData users must log in to an OData service using their Windows username (domain/user) and password.
To authenticate OData requests directly using the logged-in Windows user—and thus without requiring additional login—additional steps are necessary. First, a third-party library is required, which must be added to the /lib installation directory. To do this, copy the file `waffle-jna-1.6-with-dependencies.jar` from the installation directory `/adapter/odata/kerberos/` to the `/lib` directory. Next, restart the portal server service. In addition, the login method for the OData server must be changed to Integrated Windows Authentication. To do this, open the om.cfg file in the /internal/cfg directory of the portal using a text editor. Search within it for the line that begins with
<binding scope="odataservice" auth-type="IntegratedAuthClient"/>
Start by changing the value of the auth-type attribute to IntegratedAuth.
<binding scope="odataservice" auth-type="IntegratedAuth"/>
Repeat this step for all other OData service entries for which you want to enable Kerberos authentication. After saving the file, the portal service must be restarted.
Edge / Chrome Configuration for Integrated Windows Authentication - SSO
Since Edge and Chrome do not perform Windows authentication by default, the URL of the portal or portals must be added to the "Local Intranet." This can be done via a domain Group Policy or manually on the respective client.
Example:
-
Open the Control Panel.
-
Click Network and Internet / Internet Options.
-
In the "Internet Properties" window, select the "Security" tab.
-
Select "Local Intranet" and click "Sites."
-
Click "Advanced."
-
Enter the portal's address, such as "https://myportal.local".
-
Confirm by clicking "Add."
Trusted Authentication
With Trusted Authentication, a user can be logged in using only the user GUID. In this case, the user GUID is expected to be sent as the username in the HTTP request. This is the least secure method and should be used only in trusted environments.
Configuring the Authentication Method
The global or service-specific authentication method is defined in the om.cfg file. By default, Intrexx defines the IntrexxAuth method for all OData services. To use a different method or override the method for a specific service, open the file in the portal directory /internal/cfg using a text editor.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<authentication anonymous="05CE8CE3035924F7D3088895F1D87DADD65CFAE4">
<binding scope="web" auth-type="IntrexxAuth"/>
<binding scope="client" auth-type="IntrexxAuth"/>
...
<binding scope="odataservice" auth-type="ODataAuth"/>
...
</authentication>
/configuration>
The "scope=odataservice" entry defines the global method for all OData services. The authentication method is specified in the auth-type attribute. The following options are available:
-
ODataAuth
-
IntrexxAuth
-
PlainTextAuth
-
IntegratedAuth
-
IntegratedAuthClient
-
TrustedAuth
To override the global method for a service, copy the entry and modify the `scope` attribute as follows:
<binding scope="odataservice:MyService" auth-type="PlainTextAuth"/>
The name of the OData service from the service configuration must be specified after the colon. After saving the configuration file and restarting the portal service, the service-specific configuration will be used.