Apama 10.3 | Apama Documentation | Connecting Apama Applications to External Components | Standard Connectivity Plug-ins | The HTTP Server Transport Connectivity Plug-in | HTTP server security | Authentication
HTTP basic authentication support is provided by comparing the request authentication contents against an authentication password file supplied during configuration. We recommend that you only use this if you also have TLS enabled. For more complex use cases, webMethods Integration Server should be used.
If you are using HTTP basic authentication, you must provide a valid authentication password file using the allowedUsersFile configuration option.
This password file expected by the HTTP server for HTTP basic authentication is compatible with the output of Apache's htpasswd -B. There is also a bundled application called httpserver_passman which can create and update password files. You can find the executable for this tool in the bin folder of your Apama installation. The syntax for this is:
httpserver_passman password_file [options] username [password]
If you only provide a username and no password, then the password is prompted for interactively. This adds the specified user with the given password, or replaces the password if the user already exists in the password file.
The options are:
-h | --help
Displays usage information.
-c | --createNew
Creates a new file and overwrites anything currently there.
-D | --delete
Deletes the given user, rather than updating or adding the user.
Does not treat subsequent arguments as options. Thus, it is possible to enter a username that starts with one or two minus signs.
If HTTP basic authentication is enabled, then the authorization header is removed from metadata.http.headers, but in this case the user name is still available in metadata.http.user. If authorization is none, then the authorization type is passed through verbatim.
Note: Enabling authentication significantly reduces the maximum achievable throughput on a single connection since HTTP_BASIC requires verifying credentials on every request. It is not suitable for high-throughput applications.
Using the configuration options maxAttempts and coolDownSecs, you can protect against brute force attacks on users and passwords (see also Configuring the HTTP server transport). The initial response to a failed authentication attempt is a "401 Unauthorized" response. This response occurs until the defined number of failed login attempts (maxAttempts) has been reached. After this, the HTTP server ignores authentication attempts for the defined cool-down period (coolDownSecs). During that period, the HTTP server returns "429 Too Many Requests" with a reason of "Too many failed authentication requests, please try again later.". When the cool-down period has expired, the HTTP server attempts to authenticate any further request. If it fails that attempt, the user is immediately placed back into a cool-down period without retries.
Note: Requests from unknown users are treated in the same way as requests from allowed users to avoid user information leakage.
To protect the security of personal data, see Protecting Personal Data in Apama Applications.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.