Web single sign-on and access control software security solutions HOME  |   |  BUY  |  CONTACT US 
secure your web

Access Management White Paper

Introduction

In the early days of Internet application development, the basic security mechanisms provided by each web server was sufficient to secure a site's document and cgi-bin resources. Today, business requirements have matured to demand enterprise-scalable functionality for Internet and intranet applications (also called network applications).

A modern business may deploy dozens of network applications across multiple hosts or domains, and even between partner sites in different organizations. These sites often leverage application servers with built-in programmatic platforms such as Sun Microsystems' J2EE and Microsoft's Active Server Pages. To make this more complex, businesses desire to use the same security infrastructure for network applications as they do to address their wireless, legacy, database, and other application security requirements. And, users continue to demand greater satisfaction through ease-of-use, better performance, and new features personalized for their use!

Successful companies recognize that their security infrastructures must address these challenges. They are aware of the types of attacks that hackers can launch against their servers, and they plan appropriate defenses. However, the expanding role of network applications has increased the complexity and cost of implementing and maintaining strong security.

This white paper is written for both computing business managers and information technology professionals. The content provides a structure by which the requirements for a modern, network application security infrastructure can be measured and suggests a security platform solution to address those requirements.

What is Access Management?

Unlike firewalls and intrusion detection products, which are largely transparent to application developers, application security directly impacts design decisions. Without a unified strategy, developers re-implement custom security for each network application, which results in a variety of scalability and maintenance problems.

To combat this problem, various solutions have emerged, including access management products. As defined by the Gartner Group, “Access Management products are solutions that provide a unified mechanism to manage the authentication of users (including single sign-on) and implement business rules determining user access to applications and data.”

Some access management solutions are limited to use with web technology; others are more general purpose. For convenience, this document will address network application security. However, a flexible access management system should be able to secure anything attached to the network such as wireless devices, legacy applications, databases, network appliances, set-top boxes, and more.

To better understand the value that an access management system provides, a brief review of the following security concepts is helpful:

  • Authentication - verifying users are who they claim to be
  • Authorization - granting users access to resources (also called entitlements)
  • Auditing - recording who did what and when
  • Administration - managing users and entitlements
  • Confidentiality - protecting data from unauthorized eyes
  • Notification - actively communicating security events

Although this paper does not address network level security (which is implemented by routers, firewalls, etc.), good practice must consider its use in conjunction with application-level security.

Authentication

As in the physical world, network application security starts with the identification of the players. Verifying the identity is what authentication is all about. Joe must be able to prove he's really Joe before the bank teller gives him money. In the physical world and online, the parties involved must answer these questions:

  • Who are you?
  • To what community do you belong?
  • Are you still a trusted member?
  • How can you prove your identity?

In other words, anyone who wishes to engage in trade must both establish his identity and present a credential as proof of that identity. That may sound easy, but it can be a complex management and implementation issue. The life cycle and presentation of credentials must be managed, and credentials must be made accessible to the parties that rely on them. Depending upon business requirements, applications in the same suite may have different authentication requirements ranging from usernames and passwords, to digital certificates, to biometric identifiers. Furthermore, as network application use grows, threats increase making authentication more important.

Authorization

Authentication is merely the tip of the iceberg. It's not enough to know that Joe is Joe. One must also manage which resources and data Joe (and thousands of other Joes) can view, download, update, and change. For example, an online trading company may grant a user “Power Trader” status based on his account balance. In this case, Joe Power Trader might be visually presented with options that standard users don't even see. For good reason, authorization is often also called entitlement.

Within operating system security, groups, access-control lists, and protections clearly define who can do what. Operating systems such as Windows NT implement authorization in the kernel, which results in offloading the responsibility for application security from developers. However, if one tries to move these applications across domains or implement custom business rules, operating systems falter. This requirement of network applications has somewhat diminished the role of an operating system. Today, more and more user authorization data is moving into operating system independent directories and other databases.

Auditing

Auditing is not just the simple business case of logging access attempts or security events to remember what the good guys did, and when they did it. It also represents the process of intelligent, active event monitoring to ensure that the bad guys are found out, and to debug system and operational problems. Additionally, it is an opportunity to profile users by tracking them throughout the session to determine patterns and preferences, which can be used to enhance return visits and increase results.

Some businesses will only care about security exception events, while others may want detailed usage reports to feed into a reporting or billing system. The ability to control the level of logging and generate useful reports is an important part of network application security requirements.

Administration

Most of the issues discussed in this paper deal with technological challenges. Yet operational challenges are where much of the ongoing application security effort and cost are buried. Operational challenges are core to any application administration discussion, but are often overlooked during the application development process. How many developers who are implementing security for an individual application will stop to think about the workflow required to add new users and assign them to roles that map to application features? Or, how about considering the cost of assisting users who forget their passwords or lose a digital certificate (a problem that's exacerbated when users are required to remember multiple user identities)?

A bigger puzzle is created when network applications have user communities that span departmental and organizational lines. To avoid bottlenecks, how does one delegate user administration to trusted personnel across his own organization, or to partners outside of the firewall? Then there's the content side. Can one effectively delegate the ability to put new content online, or modify entitlements to existing content?

Though all of these criteria should be considered, they may not be required by every application at each stage of development. However, unless these issues are clearly thought through, the application security model is incomplete, and administration issues can quickly incur overwhelming costs and staff time.

Confidentiality

The Internet poses unique confidentiality issues that businesses must address to minimize risk. For example, Joe will submit information via the web only if he is confident that his financial data or medical history are kept secret. High-value business-to-business commerce demands even stronger protection. The key to confidentiality is data encryption.

Strictly speaking, encryption is the process of turning readable text into cipher text. Encryption can be a one-way process, often called a hash, where the algorithm used to create the cipher text yields the same, unique results for given inputs and prohibits deciphering by anyone, even the originator. Encryption can also be a two-way process where values are converted to cipher text and then deciphered by the receiver, provided he has received the required keys. Both of these techniques are a fundamental part of network application security.

Generally, hashes are used for saving passwords. When Joe creates a password, a hash of the password is saved to the database and the real password is tossed away. Upon login, the password Joe enters is hashed using the same algorithm. The new hash is compared with the database value and, if there's a match, Joe is authenticated. This process prevents anyone, even system administrators, from viewing the real password.

Public Key Infrastructure (PKI) cryptography and digital signature technology, applied via Secure Sockets Layer (SSL) digital certificates, provide the data integrity and privacy for securing connections used by network applications. SSL encrypts all data exchanged between web servers and users using a unique session key, which is transparently provided to the user as cipher text, along with the server's public key to do the deciphering. These layers of protection ensure that data cannot be viewed if intercepted by the bad guys.

Notification

As users interact with a network application, many security events will be generated. These events can include authentication requests, access requests, session tracking, access denials, errors, and more. Through auditing, these events are captured into logs. But what if one wants to do something intelligent with a security event immediately? This is where notification comes into play. For example, a corporate help desk administrator may want to receive an email notification any time a user fails three times while attempting to login. Or, a business program manager may want to be notified when user accounts go idle for over three months. Or, a security manager may want to programmatically inform the firewall to deny all access to a site for an IP address with suspicious behavior. Effective use of notification enhances the business processes and responsiveness of any organization.

The Case for Access Management

The complexity of modern, multi-tier applications exposes them to hacks if they are not properly configured and administered. To illustrate, consider a typical application development approach.

Developers frequently use what might be called “front-end” security. When users login to an application, a session is created, which may reside on the client or middle tier. As users access functions, usernames are available to authorize access and to log user activity. However, the architecture lacks a way to pass authenticated usernames to back-end resources like a database. Instead, all share a single database credential. In effect, the back-end trusts that:

  1. the front-end authorizes access to the back-end
  2. front-end security cannot be compromised or bypassed

Even if this trust is well placed, the back-end loses the ability to associate users with transactions. Consequently, Joe may be granted access to more services and information than he should, and back-end service logs cannot provide the context for meaningful security audits.

Obviously, security becomes increasingly complex as the number of elements and boundaries within a network application increase (web server, application server, messaging server, database server, etc). Achieving application security across platforms requires that both security products and platform elements provide integration points.

Application security is a horizontal requirement across multiple applications, platforms, and infrastructure. In general, there's no business reason why Joe should need multiple usernames. Hence, the end goal of application security should always include single sign-on (SSO). The objective of SSO is to allow users to access all applications from one login.

SSO is a boon to any organization, decreasing both complexity and costs. A side benefit of SSO is the centralization of all security logging and events. Rather than distributing logs across multiple applications and systems, a single consolidated history of security events can be intelligently mined. If someone is trying to breech multiple applications, administrators have a chance to find out.

The Role of Access Management Systems

It would be a lofty goal for any enterprise to implement all of the application security elements discussed to this point. Fortunately, most organizations can meet their business requirements by leveraging third party security solutions. The remainder of this paper discusses how a centralized access management system provides a security platform to address an organization’s network application security requirements.

Security Policies

What's a security policy? It's simply the set of business rules that govern the use of resources at a site. Drive a few million hits a day through an advanced web site, and a policy engine to process the rules becomes a necessity (though lower volume sites will also benefit). The policy engine is at the core of an access management system. It alone answers the question “Can I do . . . ?” The answer is simply yes or no, grant or deny. Yet the core value of an access management solution is defined by the policy engine logic, which should be packaged to flexibly integrate into a site and implement custom business rules.

Figure 1.0 - Proxy Network Topology

Typically, a scalable policy server hosts the engine's decision-making power. The policy server is network aware and provides a consistent security toolbox across network applications. Consequently, it must integrate with the network application infrastructure. There are two general approaches to this architectural problem. The first is fairly generic, inserting the policy server as a proxy between the users and the resources (see figure 1.0). The second approach is to integrate agents into web servers and other hosts to act as a front-line defense and propagate policy decisions back to the centralized policy server (see figure 2.0). The former is preferred for ease-of-deployment, the latter for scalability, flexibility, and performance.

Figure 2.0 - Agent Network Topology

Single Sign-on

Because the web's protocol, HTTP, is stateless, it can't “remember” a user's login. Without some way to remember, secure applications would have to re-authenticate the user for every single resource on every single page. A number of clever solutions to this problem are in use today. The most common makes use of browser-based cookies.

Cookies, though often maligned as an invasion of privacy, are quite useful and secure when properly used. When a user requests a secure resource, his browser is redirected to an authentication server, which requests that the user logs in. Upon successful login, the authentication server sends the browser a secure cookie containing authentication information, and redirects the browser back to the originally requested resource.

The browser cookie is encrypted, time-stamped to expire when the browser session ends, and digitally signed by the authentication server. Within the same domain, multiple servers and applications can share the same cookie authentication information. But, much like in real life, it's hard to share a cookie. By design, cookies are not permitted to be accessed by servers from different domains. To get around this cookie limitation (or security feature depending upon the point of view), access management systems use various techniques that involve a series of HTTP redirects. Hence, a good access management system provides secure single sign-on within, and across, multiple applications, servers, and domains.

User Repositories

Security policies, user profiles, and configuration data must be stored in a database or file. For security policies and configuration data, expressing information in a format somewhat proprietary to the access management system is usually not an issue. In fact, a clean policy server architecture will ensure that the list of security policies will be short enough to be cached into high-performance memory!

Unfortunately, this is definitely not the case for user profile information, where integration requirements are diverse, and repositories can occupy gigabytes of storage. For example, some organizations may have large amounts of user data in multiple and even heterogeneous repositories, including LDAP servers, NT domains, and SQL databases. An access management system with a proprietary user repository can add to this complexity.

An access management system should provide high-performance database lookups, along with the flexibility to integrate with existing enterprise repositories. To this end, flexible integration with existing industry standard user repositories, such as LDAP, NT domains, and SQL databases, is a must. Also, the access management system should have tools and templates for developers to write their own drivers for accessing user data in legacy repositories.

Harvesting User Data

Although dynamic information will usually be obtained and manipulated directly by the application, there are circumstances where the access management system may intervene for the developer. First, is to provide the programmer with tools to control access based on some sort of user profile data. For example, “show the free first class upgrade page only if the user has at least 50,000 air miles this year.” In this case, the logic is implemented by business rules in the policy server for potential access by a suite of applications.

Second, is to enable the programmer to fetch user data that has already been harvested by the authentication server during login. For example, it may be determined during login that the user has 50,000 air miles. The application developer can then make fine-grained decisions from this profile data to display more options or cosmetically enhance a page with “gold_customer_logo.gif”. In this case, the programmer will use either API calls or have the data returned via HTTP headers. In some cases, this shortcut saves the application developer from making database calls.

Management Delegation

Management of user profiles and policies may not always be as centralized as the policies themselves! In a corporate intranet, for example, different departments may want control over their own security policies and user administration. In fact, even though they may not want control, it may be a business requirement to avoid workflow bottlenecks. Or, organizations may have internal users and customers in the same repository, with responsibility for administration given to various personnel in customer support and human resources. In either case, the capability for an access management system to delegate both security policy and user profile administration, is critical.

The degree to which an access management system provides delegation may somewhat be a function of how it manages repositories. Most should provide excellent control over the security policy repository, but only those with highly coupled user repositories will provide fine-grained delegation of user profile data down to the attribute level. Others will provide management user interfaces that layer onto existing repositories.

Notification

The access management system can be an integral part of the audit and reporting structure of a web site, and it can also help maintain security by supporting break-in detection and other notification functions. With break-in detection, multiple incorrect passwords in a short period of time will disable an account, lock it out for a set period, or send notification to a security monitoring station. A notification service should run in a separate thread and be able to register itself to receive security events, rather than by making a decision from reviewing the contents of log files, which can be processor intensive.

Notifications can be based on frequency and time of day, and fall into categories that generate different actions such as a page, an email, a sound or dialog box, an SNMP trap, and others. The choice of notification can vary based on schedule (e.g., notify the network manager during the day, but the NOC at night). Notifications are not just for security problems, but also server problems. For example, an overload notification might trigger when an operation eats up CPU time, or when a system server or agent fails.

Performance and Reliability

Perhaps the most important topic is saved for last, because there isn't that much to say about it. Access management systems must be fast; blazingly fast. And they simply can't go down. Performance and high availability is mission critical, and is provided through features such as load sharing, load balancing, replication, and failover.

Redundancy is a key architectural element of an access management system. Virtually every component can be duplicated: policy servers, authentication servers, web agents, and back-end directories. The policy server database can be redundant and is multi-master replicated, which allows for multiple copies to be kept current around the network. Load sharing or failover, or both, across the user directory and the policy database are critical.

An agent topology is preferred to the proxy mechanism previously discussed. Agents scale the load naturally, while proxies can become bottlenecks. Agents contact the main policy server to download a list of available policy servers. Queries to each policy server are tracked for performance, with preference for the best performing policy server. If a policy server goes down, the agent will automatically choose the next available policy server. If an agent goes down, others are already available in the server farm.

Business Enablement

In addition to lowering the cost and complexity of existing network application security issues, access management systems are also a business enabling technology. For example, centralized access management solutions enable:

  • business partners a platform upon which security is implemented and administration delegated between organizations;
  • organizations to secure applications, systems, databases, devices, and more that were previously not-secure, or that were a security island;
  • a cross-platform infrastructure upon which new authentication methods (such as smart cards or a new biometric device) can be centrally implemented and delivered to users;
  • developers and administrators to use tools to test business rules and ensure there are no security holes;
  • single sign-on, both within an organization and across organizational boundaries;
  • a development paradigm where security is configured by administrators at application deployment, rather than during development.

In each of these cases, a centralized access management system provides the benefit of enabling organizations to securely create new ways of transacting with employees, customers, and partners.

The Cafésoft Access Management System

The Cafésoft Access Management System (Cams) is an easy-to-use, reliable, and cost-effective security platform that centrally controls and monitors access to secure network applications and data. Administrators decide who gets access to which resources, and then Cams enforces the policy.

Resources protected by Cams can reside on the corporate intranet, an extranet, or the Internet. They can be a document, a network application, or almost any other application, data, or even a device.

Cams makes web sites more secure and manageable by centralizing application security administration and access, rather than building access control systems into each application. This centralized approach enables companies to reduce development and administration complexity and costs, while improving time to market, application security, and user satisfaction.

Using Cams to protect multiple network applications transparently delivers single sign-on to users by sharing authentication (who you are) and entitlement (what you are allowed to do) information. You can even use Cams to facilitate trustworthy single sign-on to partner sites across the Internet.

A scalable design allows Cams to be partitioned to meet the performance requirements and network architecture of most sites. Cams utilizes caching at both the agent and server levels to ensure that the logic for frequently accessed resources is memory resident. And load balancing is achieved by distributing requests across agents on the front-end.

Cams provides native integration with industry-standard LDAP and NDS directories, as well as SQL databases. The product deploys quickly and easily into heterogeneous environments providing a centralized, robust security platform to meet the traffic requirements of high-volume sites.

An abundance of Cams programmer libraries and tools speed the application development process and security results. Java Technology™ Application Programmer Interfaces (APIs) empower developers to easily and flexibly customize Cams to meet business requirements. For example, if support is required for new authentication types such as a biometric device, the developer uses the Java Authentication and Authorization Service (JAAS) API to create a new login module. Or, if a custom rule is required to provide access based on proprietary database values, Cams libraries easily allow the developer to create and centrally deploy the new rule for use across all network applications.

Conclusion

Designing and implementing network applications with a comprehensive security solution is a complex problem. The process to solve the problem requires a solid understanding of security topics, especially authentication, authorization, auditing, administration, confidentiality, and notification.

Rather than expose an organization to the risk, time, and opportunity costs of implementing customized security for each network application, use of a centralized security platform should be evaluated. Of these, access management systems have emerged as the market leader in the network economy.

Access management systems are designed to provide a high-performance, fault tolerant framework upon which business rule driven application security can be integrated. In addition to solving security problems, access management solutions are business enabling tools. They allow organizations to securely take advantage of new opportunities and business partnerships.

Cafésoft is the developer of Cams, an access management system that is designed to meet the application security requirements of many organizations. Cams is an easy-to-use, reliable, and cost-effective security platform that centrally controls and monitors access to secure network applications and data. Cafésoft provides free developer and limited run-time Cams licenses for download, and offers professional services to integrate and customize Cams to meet customer requirements.




  OVERVIEW
  TECHNICAL PAPER
  CASE STUDIES
  BENEFITS
  PLATFORMS
  FAQ
  DOCUMENTATION
  ACCESS MANAGEMENT
  SECURITY ROI
  TOMCAT SECURITY
WEB SECURITY SURVEY
HOME  |  SITE MAP  |  PRIVACY STATEMENT  |  COPYRIGHT