In this section: |
iWay Service Manager (iSM) maintains a database of private keys that correspond to public keys published in any certificates issued for it. The server software requests the password to this database (called a key store) the first time that it needs to access it. An example would be the first time that a user attempts to access an SSL-enabled server that requires certificate-based client authentication. Key stores are managed in iWay Service Manager by key store providers, which are usually configured with the required password. Some key stores (usually those implemented in hardware such as an nCypher device), can request the password at runtime using a callback mechanism. In either case, once entered, the password need not be reentered during runtime, even when the key store is accessed by other providers or users, such as other SSL-enabled channels. This centralization of the key store access within the provider increases server security.
The client sends both the user certificate and the evidence (the randomly generated piece of data that was digitally signed) across the network. The server uses the certificate and the evidence to authenticate the user identity. At this point the server may optionally perform other authentication tasks, such as checking that the certificate presented by the client is stored in the user entry in an LDAP directory.
The server then continues to evaluate the identified user's access permission for the requested resource. This evaluation process can employ a variety of standard authorization mechanisms, potentially using additional information in an LDAP directory, company databases, and others. On determining a positive evaluation, the server enables the client to access the requested resource.
As certificates replace the authentication portion of the client/server interaction, instead of requiring users to send passwords across the network throughout the day, a single sign-on enables users to enter the private key database password just once, without sending it across the network. For the remainder of the session, the client presents the user certificate to authenticate the user to each new server it encounters. Existing authorization mechanisms based on user identity authentication are not affected.
The following certificates are commonly used with iWay products:
The SSL protocol specification defines a set of rules governing server authentication, client authentication, and encrypted communication between servers and clients. Widely used on the Internet for interactions involving exchanges of confidential information such as credit card numbers, SSL requires at least a server SSL certificate. As part of the initial handshake, the server presents its certificate to the client to authenticate its identity.
The authentication process uses Public-Key Encryption and Digital Signatures to confirm that the server is the server it claims to be. You may also configure servers to require client authentication as well as server authentication. In this case, after server authentication is completed, the client must also present its certificate to the server to authenticate the client identity before the encrypted SSL session can be established.
Many e-mail programs support digitally signed and encrypted e-mail using the widely accepted S/MIME protocol. Its use to sign or encrypt e-mail messages requires that the sender of the message have an S/MIME certificate. E-mail messages that include digital signatures provide reasonable assurance that they were sent by the person whose name appeared in the header, thus authenticating the sender.
Certificate authorities (CAs) are entities that validate identities and issue certificates. They can be either independent third parties or organizations running their own certificate-issuing server. Certificate Authority Services provides a list of third-party certificate authorities. Any client or server software that supports certificates maintains a collection of trusted CA certificates.
Data integrity is ensured using a Message Identification Code (MIC). MICs are computed hash values that are created based on the content of the AS2 message, and using the private key of the sender.
This private key is then used to sign the document. Recipients of the message can check the integrity of the message by recomputing the MIC value of the AS2 message (using the public key of the sender) and comparing the value with the MIC provided in the digital signature.
| iWay Software |