Digital certificates for user authentication
Traditionally, users receive access to resources from an application or system based on their user name and password. You can further augment system security by using digital certificates (instead of user names and passwords) to authenticate and authorize sessions between many server applications and users.
You can use Digital Certificate Manager (DCM) to associate a user's certificate with that user's IBM® i user profile or another user identity. The certificate then has the same authorizations and permissions as the associated user identity or user profile. Alternatively, you can use APIs to programmatically use your private local Certificate Authority (CA) to issue certificates to users other than IBM i users. These APIs provide you with the ability to issue private certificates to users when you do not want these users to have a IBM i user profile or other internal user identity.
A digital certificate acts as an electronic credential and verifies that the person presenting it is truly who she claims to be. In this respect, a certificate is similar to a passport. Both establish an individual's identity, contain a unique number for identification purposes, and have a recognizable issuing authority that verifies the credential as authentic. In the case of a certificate, a CA functions as the trusted, third party that issues the certificate and verifies it as an authentic credential.
For authentication purposes, certificates make use of a public key and a related private key. The issuing CA binds these keys, along with other information about the certificate owner, to the certificate itself for identification purposes.
- Telnet server
- IBM HTTP Server for i (powered by Apache)
- IBM Tivoli® Directory Server for IBM i
- IBM i Access for Windows (including System i® Navigator)
- FTP server
- There is the possibility that an individual might forget his or her password. Therefore, users must memorize or record their user names and passwords to ensure that they remember them. As a result, unauthorized users may more readily obtain user names and passwords from authorized users. Because certificates are stored in a file or other electronic location, client applications (rather than the user) handle accessing and presenting the certificate for authentication. This ensures users are less likely to share certificates with unauthorized users unless unauthorized users have access to the user's system. Also, certificates can be installed on smart cards as an additional means of protecting them from unauthorized usage.
- A certificate contains a private key that is never sent with the certificate for identification. Instead, the system uses this key during encryption and decryption processing. Others can use the certificate's corresponding public key to verify the identity of the sender of objects that are signed with the private key.
- Many systems require passwords that are 8 characters or shorter in length, making these passwords more vulnerable to guessing attacks. A certificate's cryptographic keys are hundreds of characters long. This length, along with their random nature, makes cryptographic keys much harder to guess than passwords.
- Digital certificate keys provide several potential uses that passwords
cannot provide, such as data integrity and privacy. You can use certificates
and their associated keys to:
- Assure data integrity by detecting changes to data.
- Prove that a particular action was indeed performed. This is called nonrepudiation.
- Ensure the privacy of data transfers by using the Secure Sockets Layer (SSL) to encrypt communication sessions.