Here, you'll learn how to configure a connection for the OData connector so that you can make data from an OData service available. You can find information on configuring an SAP Gateway connection here.
General Information
In the "Integration" module, you can create a new connection via the main menu under "OData / New Data Source. " To do this, the OData connector must be selected under "Consume Data" in the left pane.
The configuration of SAP Gateway connections uses the same dialog box for general information. You can find all the information you need about configuring SAP Gateway connections here.
In the general settings for an OData connection, you can specify the following entries for our example:
-
Name: Dates
-
Authentication: HTTP Basic
-
Username/Password: The username and password of a user from the portal where the service is provided. This user needs permissions for the sample application "Calendar1," from which the data in the sample service is sourced.
In addition to the name and a description of the connection, the following authentication methods can generally be configured in the general settings:
Authentication
None
For anonymous access.
HTTP Basic
This method (HTTP Basic) is used to retrieve the login information. The user to be entered here is required solely for accessing the service metadata in Portal Manager.
If you select the "HTTP Basic" authentication method, be sure to check the "Use SSL" checkbox when you create the service later. If necessary, the OData server's certificate must be imported into the certificate store of the consuming portal.
Intrexx (Legacy)
This method is suitable for services provided via the Intrexx OData provider. Login credentials are transmitted in encrypted form. To access the metadata, enter an Intrexx username and password here as well.
Kerberos / Kerberos (HTTP Basic)
These methods enable integrated Windows authentication for single sign-on in Windows environments. With Kerberos (HTTP Basic), even clients that do not support the Kerberos protocol can authenticate. Please note the following basic requirements for successful authentication with Kerberos:
-
The Intrexx portal must be operated with integrated Windows authentication.
-
The users from your Active Directory must be imported into the portal accordingly. Please make sure that at least one user is included in the Administrators user group so that the system can continue to be administered.
-
The server on which Intrexx is installed requires the "Delegation" group policy.
-
All clients and servers must be members of the same domain. In Internet Explorer, under the security settings for the zone you are using, the "User Authentication" option must be set to "Automatically log in with current username and password." In addition, the "Enable Integrated Windows Authentication" option must be selected in the advanced settings.
With Kerberos authentication, you have true single sign-on for your users' access to the OData service and use Integrated Windows Authentication. If a user cannot be authenticated, the default login is automatically enabled with the second option. To authenticate successfully, you must specify a Service Principal Name (SPN). The SPN contains information about the service for which a Kerberos ticket is to be generated. This ticket is required for the Internet Information Server of the Intrexx portal server. The SPN is typically structured as follows: http/<computer-DNS-name>@<KERBEROS_REALM>. The computer's DNS name corresponds to the fully qualified host name (e.g., mycomputer.mycompany.de). KERBEROS_REALM is typically specified as the domain in uppercase letters (e.g., MEINEFIRMA.DE). The SPN with the sample data would therefore be as follows: http/meinrechner.meinefirma.de@MEINEFIRMA.DE.
Kerberos (Intrexx Token Service)
You can find all the information here.
X.509
This method allows you to upload a certificate store in PKCS12 format. Each user can later upload their own certificate store to the browser using a login form. For authentication using X.509 certificates, the root certificate of the certification authority responsible for issuing client certificates must have been imported into Intrexx beforehand. To do this, click on 
"Upload X.509 Certificate Store."
Certificate Store
Enter the certificate's filename and password. Clicking "Search" at 
opens a dialog box where you can select the certificate file (in PKCS12 format). Click "Finish" to close the dialog box.
After the import, restart the portal service.
OAuth2/OpenID
This authentication method supports services that require OAuth 2.0 authorization from the user. If the service supports automatic user approval, the user's login credentials can be stored here for the metadata. If this is not possible, the metadata document must first be saved manually as a local file and placed in the portal directory `internal/cfg/odata` with the filename `<SERVICE_GUID>.edmx`. The actual configuration of OAuth2 authorization must currently still be performed directly in the OData consumer's XML configuration file, located in the portal directory `internal/cfg/odata`, with the filename `<SERVICE_GUID>.xml`. The relevant properties are:
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="<OAuth scopes>"/>
<property name="oauth2.authenticationScheme" value="<Schema>"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="<Grant Type>"/>
<property name="oauth2.clientAuthenticationScheme" value="<Client Schema>"/>
<property name="oauth2.userAuthorizationUri value="<end point for the authentication>"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="<Redirect URL>"/>
<property name="oauth2.accessTokenUri" value="<end point for the request of a token>"/>
The following section lists excerpts from some sample configurations for commonly used OAuth 2.0 services. Some of these services cannot be used as OData services. Nevertheless, OAuth2 authentication can be used for direct HTTP access to the service in Groovy scripts.
Spring Security OAuth2 Identity Provider
<?xml version="1.0" encoding="UTF-8"?>
<odata xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:schemas-unitedplanet-de:lucy:server:odata:consumer:cfg consumer.xsd">
<consumer description="" guid="30378A6DEDA601F69D525C7FCAFA7E12CEC114C8" name="SpringOAuth2">
<property name="authenticationType" value="OAUTH2"/>
<property name="additionalAuthenticationTypes" value=""/>
<property name="userName" value="user"/>
<property name="password" value="E54F94C0106981A41312FC14955B164C"/>
<property name="servicePrincipalName" value=""/>
<property name="isSapService" value="false"/>
<property name="sapUseDefaultClientId" value="false"/>
<property name="sapClientId" value=""/>
<property name="sapNetweaverGatewayHost" value=""/>
<property name="sapNetweaverGatewayPort" value=""/>
<property name="sapNetweaverGatewayUseSSL" value="false"/>
<property name="sapSolutionManagerRegistered" value="false"/>
<property name="authTypeSource" value=""/>
<property name="authLoginSource" value=""/>
<property name="authPasswordSource" value=""/>
<property name="authSapClientIdSource" value=""/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="form"/>
<property name="oauth2.accessTokenUri" value="https://localhost:9999/uaa/oauth/token"/>
<property name="oauth2.userAuthorizationUri" value="https://localhost:9999/uaa/oauth/authorize"/>
<property name="oauth2.scope" value="openid"/>
<property name="oauth2.clientId" value="acme"/>
<property name="oauth2.clientSecret" value="acmesecret"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<services>
<service guid="E2050082619BBD33EEDEA97BDCC9223B25244191" name="SpringOauth2" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://localhost:8888/res/" useSSL="false"/>
</services>
<userMappings/>
</consumer>
</odata>
Values in italics must be adjusted.
Microsoft Outlook Online (http only, no OData)
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="https://outlook.office.com/mail.read"/>
<property name="oauth2.authenticationScheme" value="form"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="form"/>
<property name="oauth2.userAuthorizationUri value="https://login.microsoftonline.com/common/oauth2/v2.0/authorize"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<property name="oauth2.accessTokenUri" value= "https://login.microsoftonline.com/common/oauth2/v2.0/token"/>
<services>
<service guid="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" name="Outlook" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://outlook.office.com/api/v2.0/me/messages" useSSL="true"/>
</services>
Gmail (http only, no OData)
<property name="authenticationType" value="OAUTH2"/> // value has to be OAUTH2
<property name="oauth2.scope" value="https://mail.google.com/"/>
<property name="oauth2.authenticationScheme" value="header"/>
<property name="oauth2.clientId" value="<Client ID>"/>
<property name="oauth2.grantType" value="authorization_code"/>
<property name="oauth2.clientAuthenticationScheme" value="header"/>
<property name="oauth2.userAuthorizationUri value="https://accounts.google.com/o/oauth2/auth"/>
<property name="oauth2.clientSecret"value="<Client Secret>"/>
<property name="oauth2.redirectUri" value="https://localhost/devportal/oauth2"/>
<property name="oauth2.accessTokenUri" value= "https://accounts.google.com/o/oauth2/token"/>
<services>
<service guid="XXXXXXXXXXXXXXXXXXXXXXXXXXXXX" name="GMail Inbox" odataSpecVersion="V2" sapCsrfTokenRequired="false" serviceRootURI="https://www.googleapis.com/gmail/v1/users/firstname.lastname@googlemail.com/messages/" useSSL="true"/>
</services>
Connection timeout
If the "Active" setting is selected here, you can specify the desired connection timeout as needed.
Click "Next."
OData Services
In this dialog box, you can create a new service by clicking " 
" to "create a new service."
Record Service
The same dialog is used in the configuration for SAP Gateway connections. You can find all the information here.
If you want to use our example for the OData connection, enter the name "Appointments" and the service URL in this dialog box. You can find the endpoint URL in the general information section of OData services you have created yourself. It can be copied and entered here as the service URL.
Use SSL
Enable this setting if the service requires an SSL-encrypted connection.
Use Etag
Enable this setting if so-called ETag headers need to be set for data manipulation.
OData V4
This setting allows you to consume OData V4 services. Intrexx supports a subset of OData V4 features that corresponds to the functionality of OData V2.
Click "Finish."
Click "Edit Service" at 
to edit the service settings. 
"Remove Service" deletes the currently selected service. Services can only be deleted if they are not already being used by an application or a process.
Click "Next."
Login Information
Username / Password / SAP Client ID
From User Management
With this option, the login name, password, and SAP client ID are retrieved from user administration.
From Web Input
Here, the login credentials are requested when the application that uses the connection is launched.
Click "Next."
Additional Users
Here, you can define additional users for service access, e.g., for processes in which access to the service or the system should always be performed under a specific user, regardless of the user currently logged in to Intrexx.
"Intrexx Users" Column
Displays the user's name along with the path from the user structure.
"Service Login" column
Displays the assigned service login.
/ Edit additional user
Opens a dialog box where you can select or edit an additional user.
User Selection
Intrexx Users
Displays the path and name of a selected user.
Select a user
Opens a dialog box where a user can be selected from the "Users" module.
Depending on the authentication method, you can enter a certificate file, service login, and password below.
File Name
Displays the path and name of the certificate file.
Select a file
Opens a dialog box where you can select the certificate file.
Service Login
Enter your service login here.
Password
Enter your password here.
Click "Finish" to save your changes and close the dialog box.
Delete an Additional User
Removes the currently selected user from the list.
Click "Next."
Connection Test
Click "Test" to test the connection. You can find the corresponding messages in the output field. The configuration is completed by clicking "Finish."
Edit Connection
The connection is now displayed in the right-hand pane. You can access all editing functions via the "OData" main menu or the connection's context menu when the connection is selected.
"Data Groups" Column
This displays the number of data groups that are integrated with external data groups in applications.
Kerberos (Intrexx Token Service)
The Intrexx Kerberos Token Provider is a web service that can request an Intrexx Portal Server Kerberos token for single sign-on authentication of portal users with external systems. This service is primarily needed when, while processing a user request on the portal server, multiple accesses to an external system are required, and each individual access requires a Kerberos ticket for authentication. The portal server itself has only one ticket per external system available per web request. This allows the portal server to log in to the Intrexx Kerberos token provider using the portal user's credentials and then obtain multiple tokens for the external system to process the respective requests.
System Requirements
Integrated Windows authentication must be enabled for the Intrexx portal and the connector. In addition, Microsoft Windows Server version 2008 and later are supported. Internet Information Server and .NET 4.5 must be installed on the Intrexx portal server.
Installation and Configuration
The web application for the Kerberos Token Service is located in the "adapter/odata/kerberos" installation directory as a ZIP file named "ixkrbtokenservice.zip". Extract the files to any directory on the server, for example, c:/inetpub/wwwroot/ixkrbtokenservice. Now create a new web application in IIS with the following settings:
When doing so, select an application pool that supports .NET Framework version 4.0.
Next, open the "Authentication" view for the application. There, disable all methods except "Windows Authentication." The "Negotiate" option must be selected as the provider, and kernel-mode authentication must also be enabled. Now the service can be tested in the browser. To do this, enter the URL https://localhost/ixkrbservice/api/Token in your browser. In addition, you can use the "spn" query parameter to specify the server's service principal name directly in order to test the ticket request for that server. A message like the one below should appear in the browser:
Depending on the browser, the result may be displayed as an XML or JSON document. The number of tickets to be generated can be configured in the web.config file in the service directory using the "maxTokenCount" parameter. By default, 5 tickets are created per request.
Next Steps
To use the data from the connection, integrate the connection into any application in the next step. You can find all the information here.