Neptune DXP - Open Edition · 25.0 MTS

Types of proxy authentication

The following shows an overview of available proxy authentication types.

To see how these types are entered, see Add a new authentication method

Basic

The Basic type requires a Username and a Password as authentication method.

Client Certificate

Client Certificate enables you to provide a certificate for authentication to the remote server. Certificates are created in the Certificates tool.

OAuth 2.0

By using the OAuth 2.0 authorization framework, you can grant your own applications limited access to your APIs on behalf of the application itself.

Enter your OAuth 2.0 Identity Provider details, including the Logon URL and the corresponding Name and Value for both the header and body.

Example

Headers

Example name Example value

x-<your-example-header>

<Your example value>
Body

Example name Example value

grant_type

password

client_id

6779ef20e75817b79602

client_scret

AbC123!xYz9_7vTq

Example name	Example value
`x-<your-example-header>`	`<Your example value>`

Example name	Example value
`grant_type`	`password`
`client_id`	`6779ef20e75817b79602`
`client_scret`	`AbC123!xYz9_7vTq`

To store the header and body values of the OAuth 2.0 request as encrypted, select the checkbox in the Encrypted column.

Neptune DXP - Open Edition user token (JWT)

You can use a JSON web token (JWT) for authentication. A new token with the current user as its payload (username, email, name, language) is created for every request, so the remote system sees the individual user.

Token Signing: Shared secret (HS256) signs the token with the value in JWT Secret, which the remote system must know. Instance key / JWKS (ES256) signs it with this instance’s own key; the remote system verifies it against [PROTOCOL]://[HOST]/.well-known/jwks.json and no shared secret is needed.
JWT Secret: The shared secret. Required for Shared secret (HS256).
Issuer: Optional issuer claim.
Audience: Optional audience claim, comma-separated.
Token Lifetime (seconds): How long a minted token is valid. Default 60.
Include Roles and Include Groups: Add the user’s role and security group names to the token.

To let another Neptune DXP - Open Edition instance accept these tokens and create the users on first contact, configure a JWT Validation login method there. See Configure JSON web token (JWT) API authentication and Propagate users between instances.

Neptune DXP Service Account (OAuth 2.0)

Authenticates with client credentials issued by another Neptune DXP - Open Edition instance and exchanges them for a service token. All calls act as the service user bound to the client on the remote instance.

Base URL: The base URL of the remote instance, for example https://dxp.example.com. The token endpoint is derived as [BASE-URL]/api/oauth/token.
Client ID: The client ID created in the remote instance’s OAuth Clients tool.
Client Secret: The client secret shown once when that client was created. You can enter the value or select a vault secret.

The token is cached and refreshed when it expires, after one hour.

X.509

You can use the X.509 method for authentication. This is the SAP principal propagation method.

Sign With: Select a certificate to sign-in to a SAP system. Certificates are created in the Certificates tool.
Assign user field to CN: Method by which a user is assigned to the common network (CN). It is recommended to use username but you can also use email.
Organization (O): Name of the organization.
Organizational Unit (OU): Name of the organizational unit.
Locality or city (L): Name of the locality or city.
State or Province (S): Name of the state or province.
Country Name ( C ): Name of the country

OpenID Connect Bearer

OpenID Connect Bearer forwards the access token that the logged-in user already received from your OpenID Connect identity provider to the remote system, instead of the calling app having to read and pass the token itself. This enables principal propagation to a remote system reached through SAP API Management or through the Neptune DXP - Proxy, for both proxied app requests and script or engine calls made on behalf of the user.

The token is refreshed automatically before it expires, so the remote system never receives an expired token.

No further configuration is required for this type.

The user must be logged in through an OpenID Connect authentication for this type to work. It cannot be used for anonymous or system-to-system calls.

SAML 2.0 Bearer (S/4HANA Public Cloud)

With SAML 2.0 Bearer, Neptune DXP - Open Edition calls SAP S/4HANA Cloud Public Edition APIs on behalf of the logged-in user. The platform builds a SAML 2.0 assertion identifying the user, signs it with the selected certificate, and exchanges it for an OAuth access token at the SAP token endpoint (OAuth 2.0 SAML Bearer Assertion flow). Tokens are cached per user until they expire.

The user is identified by email address. The email address of the user in Neptune DXP - Open Edition must match the email address of the business user in the SAP system.

Token URL: The OAuth token endpoint of your SAP system, as shown in the communication arrangement.
Client ID: The client ID of the communication arrangement’s OAuth client.
Client Secret: The client secret of the OAuth client. Enter the value directly or select a secret from the Vault of secrets.
Audience: The audience the SAML assertion is issued for, as expected by the SAP system.
Issuer: The issuer name of the SAML assertion. It must match the trusted identity provider configured in the SAP communication system.
Signing Certificate: The certificate used to sign the SAML assertion. Certificates are created in the Certificates tool. Upload the certificate to the SAP communication system so the signature can be verified.
Scope: Optional. The OAuth scopes to request with the token.
Clock Skew (s): Optional. Tolerance in seconds for clock differences between the systems when the assertion’s validity starts. Defaults to 60.
Validity Window (s): Optional. How long the assertion stays valid, in seconds. Defaults to 600.