Security Authentication

Security is a broad topic. Secure communication is an integral part of securing your distributed application to protect sensitive data, including credentials, passed to and from your application, and between application tiers.
There are many technologies used to build .NET Web applications. To build effective application-level authentication and authorization strategies, you need to understand how to fine-tune the various security features within each product and technology area, and how to make them work together to provide an effective, defense-in-depth security strategy. This guide will help you do just that.
There are two types of techniques for doing this.
The first is comparing the attributes of the object itself to what is known about objects of that origin. For example, an art expert might look for similarities in the style of painting, check the location and form of a signature, or compare the object to an old photograph. An archaeologist might use carbon dating to verify the age of an artifact, do a chemical analysis of the materials used, or compare the style of construction or decoration to other artifacts of similar origin. The physics of sound and light, and comparison with a known physical environment, can be used to examine the authenticity of audio recordings, photographs, or videos.
The second type relies on documentation or other external affirmations. For example, the rules of evidence in criminal courts often require establishing the chain of custody of evidence presented. This can be accomplished through a written evidence log, or by testimony from the police detectives and forensics staff that handled it. Some antiques are accompanied by certificates attesting to their authenticity. External records have their own problems of forgery and perjury, and are also vulnerable to being separated from the artifact and lost.

Authentication VS Authorization:
The process of authorization is sometimes mistakenly thought to be the same as authentication; many widely adopted standard security protocols, obligatory regulations, and even statutes make this error. However, authentication is the process of verifying a claim made by a subject that it should be allowed to act on behalf of a given principal (person, computer, process, etc.). Authorization, on the other hand, involves verifying that an authenticated subject has permission to perform certain operations or access specific resources. Authentication, therefore, must precede authorization.
For example, when you show proper identification credentials to a bank teller, you are asking to be authenticated to act on behalf of the account holder. If your authentication request is approved, you become authorized to access the accounts of that account holder, but no others.
Even though authorization cannot occur without authentication, the former term is sometimes used to mean the combination of both.
To distinguish "authentication" from the closely related "authorization", the short-hand notations A1 (authentication), A2 (authorization) as well as AuthN / AuthZ (AuthR) or Au / Az are used in some communities.
IP address:
       
          An Internet Protocol address (IP address) is a numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication.[1] An IP address serves two principal functions: host or network interface identification and location addressing. Its role has been characterized as follows: "A name indicates what we seek.
         An address indicates where it is. A route indicates how to get there."[2] The designers of the Internet Protocol defined an IP address as a 32-bit number[1] and this system, known as Internet Protocol Version 4 (IPv4), is still in use today. However, due to the enormous growth of the Internet and the predicted depletion of available addresses, a new addressing system (IPv6), using 128 bits for the address, was developed in 1995,[3] standardized as RFC 2460 in 1998,[4] and is being deployed world-wide since the mid-2000s.
           IP addresses are binary numbers, but they are usually stored in text files and displayed in human-readable notations, such as 172.16.254.1 (for IPv4), and 2001:db8:0:1234:0:567:8:1 (for IPv6).
           The Internet Assigned Numbers Authority (IANA) manages the IP address space allocations globally and delegates five regional Internet registries (RIRs) to allocate IP address blocks to local Internet registries (Internet service providers) and other entities.
IPv4 private addresses
Early network design, when global end-to-end connectivity was envisioned for communications with all Internet hosts, intended that IP addresses be uniquely assigned to a particular computer or device. However, it was found that this was not always necessary as private networks developed and public address space needed to be conserved.

Computers not connected to the Internet, such as factory machines that communicate only with each other via TCP/IP, need not have globally-unique IP addresses. Three ranges of IPv4 addresses for private networks were reserved in RFC 1918. These addresses are not routed on the Internet and thus their use need not be coordinated with an IP address registry.
Any user may use any of the reserved blocks. Typically, a network administrator will divide a block into subnets; for example, many home routers automatically use a default address range of 192.168.0.0 - 192.168.0.255 (192.168.0.0/24).

Methods
          Static IP addresses are manually assigned to a computer by an administrator. The exact procedure varies according to platform. This contrasts with dynamic IP addresses, which are assigned either by the computer interface or host software itself, as in Zeroconf, or assigned by a server using Dynamic Host Configuration Protocol (DHCP). Even though IP addresses assigned using DHCP may stay the same for long periods of time, they can generally change. In some cases, a network administrator may implement dynamically assigned static IP addresses. In this case, a DHCP server is used, but it is specifically configured to always assign the same IP address to a particular computer. This allows static IP addresses to be configured centrally, without having to specifically configure each computer on the network in a manual procedure.
        In the absence or failure of static or stateful (DHCP) address configurations, an operating system may assign an IP address to a network interface using state-less auto-configuration methods, such as Zeroconf.

Uses of dynamic addressing
          Dynamic IP addresses are most frequently assigned on LANs and broadband networks by Dynamic Host Configuration Protocol (DHCP) servers. They are used because it avoids the administrative burden of assigning specific static addresses to each device on a network. It also allows many devices to share limited address space on a network if only some of them will be online at a particular time. In most current desktop operating systems, dynamic IP configuration is enabled by default so that a user does not need to manually enter any settings to connect to a network with a DHCP server. DHCP is not the only technology used to assign dynamic IP addresses. Dialup and some broadband networks use dynamic address features of the Point-to-Point Protocol.

Modifications to IP addressing

IP blocking and firewalls
            Firewalls perform Internet Protocol blocking to protect networks from unauthorized access. They are common on today's Internet. They control access to networks based on the IP address of a client computer. Whether using a blacklist or a whitelist, the IP address that is blocked is the perceived IP address of the client, meaning that if the client is using a proxy server or network address translation, blocking one IP address may block many individual computers.
IP address translation
          Multiple client devices can appear to share IP addresses: either because they are part of a shared hosting web server environment or because an IPv4 network address translator (NAT) or proxy server acts as an intermediary agent on behalf of its customers, in which case the real originating IP addresses might be hidden from the server receiving a request. A common practice is to have a NAT hide a large number of IP addresses in a private network. Only the "outside" interface(s) of the NAT need to have Internet-routable addresses.[8]
Most commonly, the NAT device maps TCP or UDP port numbers on the outside to individual private addresses on the inside. Just as a telephone number may have site-specific extensions, the port numbers are site-specific extensions to an IP address.
the task.


Secure by SSL and Client Certificates:
SSL & Client certificate:

SSL :

The Secure Sockets Layer (SSL) is a protocol designed to provide encrypted communications on the Internet. It uses a combination of symmetric-key and public-key cryptography to create a secure connection.
SSL secures transactions, preventing eavesdropping, tampering, and impersonation. It provides encryption, tampering detection, and authentication.
The Secure Sockets Layer protocol is a protocol layer which may be placed between a reliable connection-oriented network layer protocol (e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy.
The protocol is designed to support a range of choices for specific algorithms used for cryptography, digests, and signatures. This allows algorithm selection for specific servers to be made based on legal, export or other concerns, and also enables the protocol to take advantage of new algorithms. Choices are negotiated between client and server at the start of establishing a protocol session.

Session Establishment

The SSL session is established by following a handshake sequence between client and server, as shown in Figure 1. This sequence may vary, depending on whether the server is configured to provide a server certificate or request a client certificate. Though cases exist where additional handshake steps are required for management of cipher information, this article summarizes one common scenario: see the SSL specification for the full range of possibilities.
Simplified SSL Handshake Sequence

The elements of the handshake sequence, as used by the client and server, are listed below:
1. Negotiate the Cipher Suite to be used during data transfer
2. Establish and share a session key between client and server
3. Optionally authenticate the server to the client
4. Optionally authenticate the client to the server
The first step, Cipher Suite Negotiation, allows the client and server to choose a Cipher Suite supportable by both of them. The SSL3.0 protocol specification defines 31 Cipher Suites. A Cipher Suite is defined by the following components:
• Key Exchange Method
• Cipher for Data Transfer
• Message Digest for creating the Message Authentication Code (MAC)
These three elements are described in the sections that follow.



Encryption

Encryption is the translation of readable information, called plaintext, into an unreadable form, called ciphertext. To read the ciphertext, you must have the key that translates or decrypts the ciphertext to the original plaintext.
Cryptography systems are largely classified as using either symmetric-key cryptography or public-key cryptography. The SSL protocol employs both techniques.

Symmetric-key Cryptography
Symmetric-key cryptography uses a single secret key that both the sender and recipient have. Symmetric-key systems are simple and fast, but their main drawback is that the two parties must somehow exchange the secret key in a secure way.
Public-key Cryptography

Public-key cryptography uses a pair of keys that work together to encrypt and decrypt information. One key is freely distributed (the public key). The sender uses the public key to encrypt messages to the recipient. The other key is kept secret (the private key). The recipient uses his or her private key to decrypt messages from the sender. The private key will only work with its corresponding public key. The public key and corresponding private key are sometimes referred to collectively as the key pair.
Covalent SSL and Encryption

The SSL protocol uses both public-key and symmetric-key techniques to securely transfer information. Covalent SSL allows your Covalent Enterprise Ready Server (SSL-enabled server) and browsers (SSL-enabled clients) to use encryption to establish and conduct secure SSL sessions.

SSL Session

After the SSL handshake establishes the encrypted connection, the SSL session begins. During this phase, the server and client transmit the message contents. The faster symmetric session key encrypts the messages.
To detect whether the data was altered enroute during the SSL session, a message digest helps verify the integrity of the message. The message digest is also encrypted using public-key techniques. (See "Tamper Detection" for more information.)


Ciphers and Cipher Suites
Mathematical algorithms called ciphers perform encryption. Each of the encrypted exchanges in the SSL handshake and SSL session can use different types of ciphers. These ciphers have an identifying algorithm name.
Encryption Strength

Encryption strength is defined in part by the length of the keys used to perform the encryption. Key length is measured in bits-a greater number of bits provides a higher level of security. A private key with 1024-bit encryption is stronger than a private key with 512-bit encryption. A session key with 128-bit encryption is significantly stronger than a session key with 40-bit encryption. Encoding with a 128-bit session key is commonly referred to as "strong encryption".
Because the client (browser) may or may not support higher levels of encryption, the client and server negotiate the strongest cipher suite available to both during the SSL handshake.
If you want to communicate only with browsers that support the strongest ciphers, you can exclude the weaker ciphers through theSSLCipherSuite and SSLProxyCipherSuite directives. If you do so, be sure that browsers accessing your site can support the ciphers you specify.
Server Certificates, and Certificate Authorities
Private Key, Public Key and Temporary Server Certificate

You begin by using Covalent SSL to generate a temporary server certificate and its corresponding private key. The private key and temporary server certificate are always generated together because the certificate contains the corresponding public key.
The temporary certificate is signed with your server's private key (self-signed) and is valid for 30 days. Browsers won't automatically trust the temporary certificate, but you can use it to verify certificate contents and test secure HTTPS connections to your site.

Certificate Signing Request (CSR)

Covalent SSL also generates a Certificate Signing Request (CSR). The CSR is an unsigned version of the server certificate. You submit the CSR to the Certificate Authority of your choice for verification and signing.

CSR Processing and Certificate Installation

After the CA processes your CSR, which can take several business days, the CA will sign your server certificate with its private key. Use the Covalent SSL Certificate and Key Management Tool to install the signed certificate on your server.
After you install the CA-signed certificate, you are ready to conduct secure transactions. Browsers that access your Covalent SSL-secured site will examine your server certificate and authenticate your site, then proceed to transmit information safely and securely.

Certificate Expiration

When the CA signs your certificate, they also encode an expiration date. The certificate's expiration date is normally one year from the date of issue. To ensure that the certificate remains valid, be sure you renew the certificate with the CA prior to the expiration date.
SSL and Virtual Hosts
The Covalent Enterprise Ready Server allows you to secure multiple sites using Covalent SSL and its virtual host feature. To do so, you must generate a private key and install a server certificate for each host you want to secure.Because SSL negotiation occurs before the server host name is resolved, you must configure IP-based virtual hosts. Name-based virtual hosts cannot be used with the SSL protocol.

SSL Handshake

The SSL handshake establishes the encrypted connection. This is accomplished in part by authenticating the server to the client. Authentication involves digital certificates, which employ public-key encryption techniques. (See "Authentication" for more information.)
During the SSL handshake, the server and client exchange a symmetric session key. The session key itself is encrypted using public-key techniques, so only the intended recipient can decrypt it.

A SSL handshake is performed to setup a secured channel. The main process is:
1.  Server presents client a server certificate and client authenticates server;
2.  Client generates premaster secret and encrypt it with the server’s public key (contained in the server certificate), and send it to server.
3.  Server decrypts the encrypted premaster secret.
4.  Client and server both generates a master secret from the premaster secret, and then generate session keys from the master secret. The session keys are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
After this handshake, the server and client can communicate using encrypted messages that can only be decrypted by each other.

What Does a Client Need to Do to Use SSL?

A client using SSL could be a web browser or a web service proxy. As a browser client, just make sure the URL address of the server starts with “https://“ instead of “http://“. As a web service client, just make sure that when the proxy class is generated, say using wsdl.exe, the used URL starts with “https://“. Otherwise wsdl.exe can not find the WSDL of the web service and the generation will fail. Apart from these concerns there is no other things that a client has to do to use SSL.

Client Certificate

A client certificate is used for two purposes:
1.       Prove the identity of the client (more precisely, identity of his/her browser) to servers that accepts client certificates. Client no longer needs user name and password to log on to the server.
2.       Sign or encrypt user’s email. For most email applications such as Outlook or Eudora, signing or encrypting one single email or all emails are just a matter of one button click or one security setting. If user A wants to send an encrypted email to user B, A should acquire B’s public key (most email applications has the facility to store recipient’s digital IDs), and encrypt email with it. Then when the email reaches B, he can decrypt it with his private key.
The principle and authentication process of a client certificate is almost the same as a server certificate. The differences are:
1.       Client browser sends the client certificate to server, while the server sends the server certificate to client browser;
2.       A server is stationed – it resides on a fixed IP address, which is stated in the server certificate. Therefore, if someone steals the server certificate of IBM and installs it on his own server, client browser finds out that the lunching IP address of the server is different from that on the certificate.
In comparison, a client is mobile. The email address signature of the client email is also easily forgeable. Because of this, the client authentication process has one step which is different from the server authentication: the client browser is required to sign a piece of randomly generated data and send it along with the client certificate. Server is then able to verify using the public key contained in the client certificate that this piece of data was signed by the matching private key. Because of the assumption that only the real client has this private key, server can be sure that the connection was from the real client.

Using a Client Certificate

Installing your client certificate on your browser
You go through similar process to apply for a client certificate from a CA. Again trial certificates are usually provided for free. To install it, go to “Tools | Internet Options | Content tab page | Certificates button | “Personal” tab page | Import”. Browse to the certificate file.
Setting server to ignore, accept or require client certificate
IIS | “Default Web Sites” | right-click the virtual directory that needs to use SSL | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Edit” button | “Client Certificates” group | select the corresponding button.
Setting web service proxy to send client certificate
A client browser that has client certificate installed knows to send the certificate to server. But a proxy doesn’t know the certificate. Therefore, you have to export the certificate to a file, then assign it to the proxy. To export the certificate into a file in IE 6.0: Tools | Internet Options | Content | Certificates | Personal tab page | select the certificate that you want to export | click “Export...” button.
To assign it to the proxy:

Client.localhost.Service1 s = new Client. localhost.Service1();
X509Certificate cert = X509Certificate.CreateFromCertFile("c:/TrialId.cer");
s.ClientCertificates.Add(cert);
Console.WriteLine(s.Hello());
Acquiring certificate details at server side
By acquiring the details of the client certificate, server can find out the identity of the user.

[WebMethod]
public string Hello()
{
    return Context.Request.ClientCertificate.Subject;
}
The output should be something like:

E = frank_liu_silan@hotmail.com
CN = Silan (Frank) Liu
OU = Digital ID Class 1 – Microsoft
OU = Persona Not Validated
OU = www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD98
OU = VeriSign Trust Network
O = VeriSign, Inc.
If we want to acquire the email address or the user name, for example, we should parse this string.

Mapping client certificates to Windows accounts
We could map client certificates to Windows accounts, so that we do not need to acquire the certificate details and parse them. To setup server to map client certificates: go to IIS |  “Default Web Sites” | right-click the virtual directory that needs to use SSL | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Edit” button | tick “Enable client certificate mapping” tick box | “Edit” button.
There are two ways of mapping. One-to-one mapping maps one client certificate file to one user account. Obviously you should have the client certificate file (.cer) at hand. IIS does not check whether the user account actually exists or the password is correct. Many-to-one mapping maps any client certificate whose certain fields contains certain substring. For example, we can decide that any client certificate whose “Subject” field | “O” sub field begins with “Sealand Consulting” (by using a criteria “Sealand Consulting*”) maps to user account “fliu2000/Administrator”.

Conclusion

With the genius invention of the cryptographic public/private key algorithm, with the involvement of a trustworthy third party such as VeriSign, secured connection and identity verification are made possible across the Internet, which is the most important corner stone of today’s booming e-commerce industry.