Security continues to be a top concern for all businesses, regardless of size. Mistakes can be costly, embarrassing, and often highly-publicised — all of which can result in an adverse impact on your brand and your reputation amongst partners, suppliers and customers.

In Part I of this three-part series, we will look at identification, authentication and authorisation — collectively, these security services are responsible for access control to all applications.

Our Reference Model: ISO 7498-2

The ISO 7498-2 standard provides a reference model for communicating between open systems. It also specifies a set of security services, which provides a useful framework when thinking about application security:

1. Identification: Who are you?
2. Authentication: How do I know you are who you claim to be?
3. Authorisation: What operations and resources are you allowed to access?
4. Confidentiality: How do we prevent others from seeing what you send me?
5. Integrity: How do I know that what you send me hasn’t been tampered with?
6. Non-repudiation: How can we ensure that the sender cannot refute the validity of a message?
7. Auditing: Are we keeping accurate records of all activities and transactions?

Identification: Who are you?

You usually identify yourself with a username or customer number.

Authentication: How do I know you are who you claim to be?

You can prove your identity with something you know (like a PIN or password), with something you have (like a USB dongle or a smartkey), or with something you are (like a fingerprint or retinal scan).

• Two-factor authentication can be used for additional security — this simply means that you must authenticate with two of the above methods. For example, some online banking sites require you to authenticate using a PIN (something you know) and a RSA security token (something you have).

Once you have authenticated, credentials are typically created so that you do not need to authenticate again for the duration of the session (e.g., until you log out or close the browser window).

Some applications support Single Sign-On (SSO), which allows you to sign-on once and then be authenticated for multiple applications. One way in which SSO can be implemented is through Lightweight Third Party Authentication (LTPA).

• LTPA is an authentication technology used by IBM WebSphere and Lotus Domino products, and is supported by WebSEAL, a HTTP reverse proxy that is an integral part of Tivoli Access Manager (TAM). With LTPA, you must first authenticate to a server, which issues you with an LTPA token as part of a HTTP response. All subsequent requests from you contain this LTPA token — the authentication server recognises this token and does not require you to reauthenticate when accessing another application.

Authorisation: What operations and resources are you allowed to access?

Now that you’ve proven your identity, each application must decide whether you should be allowed to perform the requested operation or access the requested resource. Usually, this is accomplished by querying an access control list to determine whether you have the requisite permissions.

• An access control list (ACL) is a list of permissions attached to an object. The list specifies who or what is allowed to access the object and what operations are allowed to be performed on the object. In a typical ACL, each entry in the list specifies a subject and an operation.

For J2EE development, declarative application security is achieved by explicitly declaring security constraints in the deployment descriptor (web.xml) to govern access to one-or-more URL patterns. The deployment descriptor also defines a list of roles, and maps the security constraints to the roles that satisfy those security constraints. The J2EE container then reads these constraints and performs the access control for the J2EE application based on the role mappings.

A declarative application security approach is well-suited for governing access to resources. However, for fine-grained security (e.g., showing and hiding screen elements based on user credentials), it is necessary to use a programmatic security model. The preferred vendor-neutral way of doing this is through JAAS (Java Authentication and Authorisation Service), which has been integrated into the core Java SDK since the J2SDK 1.4.

A detailed look at using JAAS for authorisation is beyond the scope of this article, but a good starting point is http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/JAASRef....

Looking Forward…

In Part II of this three-part series, we will look at confidentiality, integrity, and non-repudiation — the fundamental security services that make secure online transactions possible!