Access Management White Paper
Access Management White Paper
Introduction
What is Access Management?
Authentication
Authorization
Auditing
Administration
Confidentiality
Notification
The Case for Access Management
The Role of Access Management Systems
Security Policies
Single Sign-on
User Repositories
Harvesting User Data
Management Delegation
Notification
Performance and Reliability
Business Enablement
Cafésoft Access Management System
Conclusion
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:
the front-end authorizes access to the back-end
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.
