Software AG Products 10.7 | Using CentraSite | Runtime Governance | Run-Time Policy Management | Built-In Run-Time Actions Reference (CentraSite Business UI) | Built-in Actions for Run-Time Policies (CentraSite Business UI) | NTLM Authentication
 
NTLM Authentication
This action uses the NTLM authentication to validate incoming requests from clients. Mediator authorizes the NTLM credentials (username and password) against a list of all global consumers available in the Mediator.
If the username or password value in the Authorization header cannot be authenticated as a valid Integration Server user (or if the Authorization header is not present in the request), a 500 SOAP fault is returned, and the client is presented with a security challenge. If the client successfully responds to the challenge, the user is authenticated. If the client does not successfully respond to the challenge, a 401 Unauthorized WWW-Authenticate: NTLM (for NTLM authentication) or WWW-Authenticate: Negotiate (for Kerberos authentication) is returned in the response header and the invocation is not routed to the policy engine. As a result, no events are recorded for that invocation, and its key performance indicator (KPI) data are not included in the performance metrics.
Note:
If Mediator is used to access a native API protected by NTLM (which is typically hosted in IIS), then the native API in IIS should be configured to use NTLM as the authentication scheme. If the authentication scheme is configured as Windows, then NTLM must be in its list.
If none of the authentication actions (HTTP Basic Authentication, NTLM Authentication, or OAuth2 Authentication) is configured for a proxy API, Mediator forwards the request to the native API, without attempting to authenticate the request.
Input Parameters
Authenticate Using
(String). Specifies the user credentials for authenticating client requests to the native API.
Note:
If Mediator is used to access a native API protected by NTLM (which is typically hosted in IIS), then the native API in IIS should be configured to use NTLM as the authentication scheme. If the authentication scheme is configured as Windows, then NTLM should be in its list. The Negotiate handshake is supported in the near future. This note applies to all three of the following options for NTLM.
Value
Description
Existing Credentials
(Default). Mediator uses the user credentials passed in the request header for an NTLM handshake with the server.
Custom Credentials
Mediator uses the values you specify in the User, Password and Domain fields for an NTLM handshake with the server.
Field
Description
Username
(String). Account name of a consumer who is available in the Integration Server on which Mediator is running.
Password
(String).A valid password of the consumer.
Domain
(String). (Optional). Domain used by the server to authenticate the consumer.
Transparent
Mediator supports Kerberos handshake in Transparent mode. The following additional settings are required for Kerberos:
*Configure the client with clientCredentialType set to Windows.
*Set the value of watt.pg.disableNtlmAuthHandler property to true in the extended settings for the Integration Server
*Set the property handleClientErrorCode to true in pg-core.xml as follows:
<bean
id="httpResponseCodeCallback"
class="com.softwareag.pg.axis2.transpo
rts.ISHTTPResponseCodeCallback">
<property name="handleClientErrorCode"
value="true"/>
</bean>
For more information about configuring the extended settings, see webMethods Integration Server Administrator’s Guide.