Authentication
The first part of securing AMPS is developing a strategy to verify the identity of connected clients. AMPS maintains an identity for each client connection, and uses that identity for entitlement requests. Once an identity is assigned to a connection, that identity stays the same for the lifetime of the connection. If an application needs to use different identities to work with AMPS, that application needs to make a separate connection for each identity.
There are two ways that AMPS assigns an identity to a client:
When an application explicitly sends a
logoncommand, AMPS uses the credentials in the message for the authentication process. If authentication is successful, AMPS associates the username provided in the initial logon with the connection. If authentication fails, AMPS closes the connection.When an application issues any other command after connecting, but before sending a
logoncommand, AMPS treats this as an implicit logon and begins the authentication process with an empty username and password. If authentication is successful, AMPS associates an empty username with the connection. If authentication fails, AMPS closes the connection. AMPS does not allow implicit logon by default in 5.0 and later versions. However, you can enable implicit logon as described below.
In both cases, authentication occurs through the AMPS security infrastructure.
When authenticating a client, AMPS locates the authentication module in use for the client's Transport (or, for the admin interface, the special amps-admin transport). If there is an authentication module specified for that Transport, AMPS uses that module. Otherwise, the Transport uses an instance of the authentication module specified for the instance. When the configuration for the instance doesn't include an instance level authentication module, the default module for the Transport is amps-default-authentication-module, which requires a logon, but accepts any username and password provided and sets the authenticated username to an empty string.
Once AMPS has located the module instance, AMPS provides the username and the password to that instance of the module. The module can accept the credentials, reject the credentials, or return a challenge that the application must respond to. When the module returns a challenge, the connection remains unauthenticated until the application requesting authentication responds to the challenge and the module accepts the response.
For most production systems, AMPS security is integrated with the overall security fabric of the organization. 60East provides the AMPS Server SDK to help developers create authentication modules that implement the unique policies and procedures required by a particular organization.
AMPS does not, itself, enforce an explicit timeout on the authentication process. However, the thread used to authenticate is managed by AMPS, so if the authentication process takes an extended period of time, AMPS may report a potentially stuck thread or (in extreme cases) prompt a server shutdown. 60East recommends that the authentication process complete as quickly as possible, especially since the authentication process will limit how quickly clients can connect to AMPS. The process should generally be subsecond if possible, and 60East recommends that the process not take longer than 30 seconds, even if the authentication server is under load.
Simple Authentication Modules
AMPS includes three simple authentication modules in the AMPS distribution. These modules provide very simple policies for authentication, and are most useful in testing and development environments.
amps-default-authentication-module
Allows any username and password. Does not allow implicit logon by default. Does not provide the username to AMPS by default.
amps-implicit-authentication-module
Allows any username and password. Allows implicit logon by default. Does not provide the username to AMPS by default.
amps-default-no-authentication-module
Does not allow authentication regardless of the username and password provided. This can be useful for testing application behavior when logon is denied, or for setting a policy for the instance that individual transports must override.
Enabling Implicit Logon
60East recommends using explicit logon commands in your applications wherever possible, and the default authentication module disallows implicit logons. For backward compatibility with older versions of AMPS, AMPS includes the amps-implicit-authentication-module which allows implicit logon to restore the behavior of the previous AMPS versions. To use the amps-implicit-authentication-module for all of the transports in the instance, set the instance level Authentication to use this module, as shown below:
Last updated