Sunday, February 13, 2011

Security Support Provider Interface (SSPI)

Tip   : SSPI is a common interface between transport-level applications, such as Microsoft Remote Procedure Call (RPC), and security providers, such as Windows Distributed   Security. SSPI allows a transport application to call one of several security providers to obtain an authenticated connection. These calls do not require extensive knowledge of the security protocol's details.

Details  Applications initialize SSPI using the following steps to secure a network connection for most security packages:

  • Using SecBufferDesc and SecBuffer
Communication often involves potentially large amounts of data or data of unknown length. Sending and receiving data is done in similar or identical fashion in both of these cases. To deal with unknown length and potentially large amounts of data, SSPI communication is done using two structures, SecBufferDesc and SecBuffer.

  • Initializing SSPI
The following steps initialize SSPI:
Ø       Writing and Installing a Security Support Provider
Ø       Initializing the Security Package
Ø       Getting Information About Security Packages
Ø       Using Security Packages

  • Establishing a Secure Connection with Authentication
In a client/server application protocol, a server binds to a communication port such as a socket or an RPC interface. The server then waits for a client to connect and request service. The role of security at connection setup is two-fold in the case of mutual authentication:
Ø       Client authentication by the server.
Ø       Server authentication by the client.

  • Ensuring Communication Integrity During Message Exchange
The client or server passes the security context and a message to the MakeSignature function to generate a secure signature that prevents the message from being modified while in transit. The receiver of the message calls the VerifySignature function. VerifySignature uses the information in the signature to verify that the message received was not modified during transmission. The client and server can also exchange encrypted messages using EncryptMessage (General) and DecryptMessage (General).

  • Ending an SSPI Session
After the client and server have finished communicating, both sides call the DeleteSecurityContext function with their respective context handles. When the client has finished communicating with any server or has finished using the additional credentials passed to the AcquireCredentialsHandle function, the client must call the FreeCredentialsHandle function. When the server is ready to shut down and before unloading the DLL, the server must call DeleteSecurityContext.


Posted By : Rijesh T.K.

No comments:

Post a Comment