# Authentication Agents

The RSA SecurID solution provides two-factor authentication to protect access to data and applications. This access can be through remote dial-in connections, local access, domain and terminal services access, Internet and VPN connections, intranet and extranet applications. The SecurID solution consists of an Authentication Manager server, an authentication agent that communicates with it, and authenticators that provide the tokencode. The authentication agent initiates a SecurID authentication session when a user attempts to access a protected resource. It verifies data provided by a user with data stored in the Authentication Manager server. Based on the result, the user is either allowed or denied access. Apart from the RSA SecurID Agent, RSA also provides authentication agent APIs which can be used to develop a custom agent to communicate with the Authentication Manager server. These APIs are available as a dynamic library (.jar, .dll, or .so). Using these APIs, you can develop custom agents to protect required resources. ## Functioning of an Authentication Agent An agent created using the RSA Authentication Agent APIs performs the steps detailed below in a secure manner. Intercepts all access attempts, such as attempts to log on or access a URL. Determines whether the specific requested resource is protected by RSA SecurID: If the requested resource is not protected, the agent either ignores the request, or takes appropriate action, such as writing an audit message in the UNIX syslog or in the Windows Event Log. If the requested resource is protected by RSA SecurID, the agent continues the authentication process. Prompts the user for the user name so that Authentication Manager can validate that the tokencode is generated from the authentication device registered to that user. Locks the user name to prevent replay attacks when Authentication Manager replicas are deployed (not available in RSA Authentication Manager 7.1). Requests the user for passcode. Combines the passcode with a secret known only to the agent and its associated Authentication Manager in the realm, and delivers the combined data to a server for validation: If Authentication Manager approves the request, the agent grants access to the protected resource and takes other appropriate actions. If Authentication Manager denies access, the agent prevents the user from accessing the protected resource and takes other appropriate actions. In addition to providing basic access checks during standard authentication, agents also handle several security-related housekeeping tasks, such as those related to Next Tokencode mode and New PIN Mode. In the Next Tokencode mode, the Authentication Manager requests for the next tokencode displayed on the user’s token. If the next tokencode is not properly sent to the Authentication Manager, the authentication fails. The Authentication Manager administrator determines that the user associated with a particular token requires a new PIN. The administrator determines the characteristics of PINs, which your custom agent can test using the API functions. It is the agent you create, and not the API that handles all user input and user output associated with processing an authentication request. Top