About authentication systems

Many authentication systems require that the participants be directly connected to each other and able to interact on a real-time basis. For instance, the client may need to respond to a challenge in order to be authenticated. On the other hand, some authentication systems require a token or a password to be passed on as proof of identity. This information could be passed through intermediate relay points so long as the information is protected or the relay is trusted.
 
This is a big factor in deciding what authentication method to use. Since the client workstations are not generally administered by the same organization as the server, it is common for application developers to be told that no additional software can be installed on the initiator’s workstation. With Internet applications, the initiator’s ties to the server’s organization are loose at best. Requiring the initiator to load more software on her workstation, when there is nothing to enforce compliance, is problematic. Additional software requirements at the client may turn customers away.
 
Must authentication be performed transparently to the application? Or, can the application be modified to add authentication?
 
Some applications provide interception points. These are predefined points during program execution, including one for authentication, which can be used to insert code to customize the application. Other applications that don?t have these intercept points require access to source code in order to support additional security measures. Adding authentication systems to such applications cannot be done transparently to the appli-cation. Adding security to such applications requires access to source code. In such cases, the application can be responsible for authentication.
 
Top