The Components of Web Application Security

May 31, 2001
Application security has three main components: authentication, accesscontrol and audit. Each of these areas involves choices and compromises thataffect the balance between costs, risks and values.

The process of reliably identifying the individual orapplication that is requesting access to a resource. Because no security schemecan be any better than its authentication, particular attention should be paidto this area.

If your Web application is not certain who the requester is, then it can'tpossibly properly resolve whether or not to grant access to a resource on theserver no matter how sophisticated the access control algorithm is. There aretwo basic options for user authentication in a Web environment: password matchor digital certificate.

ID and Password Match
ID and password match authentication is the mostcommon and less secure method of determining who or what is making the accessrequest. The concept is very simple.

In the case of a human user, the server prompts the user for a user ID andpassword. The user ID looks up a record in a database, and the password enteredis compared to the password in the database for that user. If they match, theuser is authenticated. This authentication method sends the password over thenetwork, where it is exposed to interception. The difficulties and securityrisks in maintaining synchronized ID and password databases make a single loginimpractical with this method.

Digital Certificate
Digital certificates (or public-key certificates) arestrongly encrypted blocks of data stored in a file containing digital keys usedto encrypt and sign data. A digital certificate can be thought of like an IDcard that identifies you to the server over the network. This digital ID card isissued by a trusted source called a certificate authority. Contained within thiscertificate is the name of the certificate authority that issued it, a user'sdistinguished name, the user's public key, the validity period of thecertificate and other information.

When the certificate is opened (or activated) by the user's secret passwordphrase, it becomes available for use by compatible browsers. The secret passphrase is never sent over the network, and therefore, it cannot be intercepted.

Data encrypted with a certificate's private key can only be decrypted usingthe certificate's public key. This unique feature allows trusted encryption keysto be passed between the browser and the server for the establishment of SSL-(s-cure sockets layer) encrypted sessions. In addition to the encryptedcommunications link, the certificate provides extremely reliable authenticationof the user and may provide the basis for a single login across applications.

Digital public key certificates provide for digital signing of data andforms. Your digital signature, once tied to an object, can be easily verifiedwith your public key. This non-refutable digital signature is required forpaperless workflow applications replacing paper, ink and "snail" mailmanual processes. The strong encryption algorithms make it impossible to derivethe private key or pass phrase from the certificate.

Expired or revoked certificates, password rollover and server crosscertification can make digital certificates difficult to deploy and manage inlarge corporate environments. If that describes your environment, look for avendor who pro-vides a full key management infrastructure including revocationchecking and key history. Otherwise, you could be over-whelmed by keyadministration requirements.

Most digital certificates are files stored on a local PC hard drive, but theycan also be stored on smart cards, floppy disks, network drives or even on alightweight directory access protocol (LDAP) compliant directory server. Whendigital certificates are stored on local hard drives, employees can become tiedto particular terminals to do their work.

This can be a productivity limiting drawback in those corporate environmentswhere busy professionals are accustomed to logging in and working from anyterminal they happen to be near. Roaming solutions are available to address thislimitation and are discussed later in this chapter. Digital certificates areusually licensed from a certifying authority or a public key infrastructurevendor.

Access Control
The process of granting or rejecting access to aprotected resource to an authenticated individual or application. Access can begranted or restricted on the basis of a simple access control list (ACL), adirectory-based access control list or more sophisticated role-based security.Which method you choose has a lot to do with how much manpower is required tomaintain effective and productive control over access to restricted resources.
List-Based Security
Based on discrete entries in an access control listor lists. This is the simplest way to implement security. Most Web servers havesome sort of access control list support. This list is usually a proprietaryformat that cannot be shared among multiple servers.

This means that multiple servers would each require their own access controllist creating multiple places to re-quire entries and updates for each personrequesting access. This simple access control method is easy to initiate buthard to maintain, especially with a large employee population.

The administrator would need to add a new user to each list along with theindividual file and directory access rights. Each of those access rights wouldhave to be changed when employees move. The administrator would also have toremove terminated employees from all lists.

With an average number of applications with differing levels of privilege foreach, a single employee move could involve dozens of access control listmodifications by the administrator. This is not the solution for anything butthe smallest of companies with few deployed intranet applications. Therefore,there is no practical way to implement employee self-service with list-basedsecurity.

Directory-Based ACL Security
Similar to list-based security except thatthe access control list is replaced by an LDAP directory containing user IDs andaccess control attributes. The advantage of directory-based ACL security overlist-based security is that multiple servers can share a common securitydirectory, and access privileges are assigned in attributes tied to a directoryentry (employee). This directory can contain other personnel information andfunction as the source of a corporate directory application. This represents animprovement over list-based security and a reduction in the administrativesupport required to maintain access control lists.

Nevertheless, the significant administrative effort would limit thepractical, supportable size of a directory-based ACL implementation to athousand or so users. Therefore, there is no practical way to implement employeeself-service with directory-based ACL security.

Role-Based Security
Grants and denies access based upon the position andjob function of the requester and/or the requester's relationship to the personwhose record was requested. Because role-based security implies that therequester- to-requester record relationship be known, this is the only accesscontrol method that can support employee self use. Role-based security requiresaccess to position and organizational information in order to resolve theserelation-ships.

This position and organizational information can come from an existing HRMSdatabase or, if you have one, an LDAP-based personnel directory. Role-basedsecurity can dramatically reduce access control security administration time. Infact, if properly implemented, security administration can be cut to near zero.

If intranet applications are built so they grant access to data according toposition, organization and reporting relationships, and if that information iscoming from the HR system, no other security administration is required.

When a person's position is changed in the HR system, the new position willdetermine what and whose information can be accessed. Security table entries,access control lists or attributes don't have to be changed at all.

Security Audit Log
Without an audit trail, security isn't really viable. Anaudit log must reliably record HRMS access events with sufficient detail andin-formation content to support investigation of apparent data anomalies. At thevery minimum, the audit log should contain fields for access requester,re-quested resource, requested record, read/update, date, time and workstationID address.

No serious investigation of a security breach or employee misconduct would bepossible without this information.

You certainly need this information to support litigation involving employeetransactions. Most audit logs record to a flat sequential file or to arelational database table if you log onto a database, index on requester,resource and re-quested record. This permits quick reporting on the twomost-often needed queries: show who has done what to a particular record andshow what a particular employee has done to anyone.

An additional advantage to database logging is that queries can be submittedonline in real-time. Database logging can be a significant resource drain on aheavily used system. You may need to weigh the performance penalty of databaselogging against its reporting convenience.

By Robert H. Fortenberry, Information System Consultants. From IHRIM's"e-Work Architect: How HR Leads the Way Using theInternet."