|
The following paper was written by David Whitehurst, an independent contractor. It was prepared for a state government client as a first proposal for the installation of JBoss in promotional test, integration, and production environments. This is not the submittal for approval to the final enterprise solution. This document is closed for editing 7-1-2008. Introduction In the world of business today, the internet plays a big role in how you handle data, its administration, and storage. Everyone is concerned about security and that's why it seems like every application we open requires another password. Microsoft has a built-in identity solution called Active Directory. This is used by many companies utilizing a Microsoft LAN/WAN (network) to require domain-level authentication on the network. This network authentication doesn't prevent any application running on this network from waiving its authentication if needed. However, if your network users work with many applications, it's very likely that they are entering a user and password many times a day. It's also common to find that these applications will manage their own user accounts (including passwords). The level of security implementations with each application may vary. An enterprise security solution should not consist of multiple application authentications. Authentication presents the question, "are you who you say you are?" When a user enters a password correctly, our systems assume the answer is yes, however, many forget that this question may be a lie because the password encryption was compromised, someone else saw the password, or they heard it and used it later, etc. The system or application is happy because the password was correct and therefore it has no further question of identity. When each application in an enterprise has it's own authentication, it's as if each department, section, individual, etc. responsible for an application believes that it should implement another security solution. This is not a good philosophy. While one department, section, individual, etc. may be a security expert, another may not. Identity management should be a single enterprise service. Service oriented architecture (SOA) should be well understood and well documented. A single identity management system should require that each enterprise user identify herself and the system provide a fail-safe mechanism for this verification. Problem Identification Here at the Client Center, there are two specific systems of identification, facility entry and network entry. Each employee at Client must present a badge or be screened by a security guard before entry into a Client facility. All entries and exits are secure. Also the level of scrutiny is higher for those that do not have a badge. Network entry has one entry and exit as well. These entries and exits are maintained by one or more system administrators using Microsoft's Active Directory. This user identification provides a high quality and very secure solution for identity management. What it does not do, however, is provide any assurance that this same username will be using the applications within the network boundary. And, when identity management is implemented at the application level, network identity is lost. Only active directory usernames should be used and/or identified. Enterprise security should truly separate authentication from authorization. It's very common that web applications require user and password logins. "Why?", you would ask. Very often the response is "because we need to protect this application from outside threat." Let's examine security closely for a moment. The Oxford American dictionary defines security as the state of being free from danger or threat. Security is important because any application hosted on an intranet or the internet is subject to intrusion by unwanted visitors. And when your application is exposed to such threats, you need to protect it. Before you learn how to protect your applications, you should understand the two key concepts that define application security, authentication and authorization. Authentication If someone asks you for permission to do something, you first want to know who is asking and you then question yourself to be sure that you have identified this person correctly. In security terms, this person is a principal. A principal is the entity that is requesting access to a secure resource. An application that has secured its resources will first want to identify these principals that request access to these resources. This identification is called authentication. Authentication is the act of proving that the principal is genuine or real. This is normally done by requesting for a password input with computer programs. If the user can provide the correct password, then she must be genuine. Many different technologies are employed by computer systems to verify identity. Some of these are public key cryptography, Kerberos, Java Cryptography Extension (JCE), Java Authentication and Authorization Service (JAAS), Secure Shell (SSH), Encrypted Key Exchange (EKE), Secure Remote Password Protocol (SRP), Lightweight Directory Access Protocol (LDAP), HTTP authentication methods, etc. These technologies are termed as authentication providers. Client's network presently uses Microsoft Active Directory to prove identity using user/password authentication at network login. Please note that the levels of security between these different providers may vary greatly. Authorization Authorization provides access to system resources or methods once the principal has been identified. Authorization is usually based on predefined user roles. Normally, an application only has a few roles. Most commonly this is a user role and an administrative role. There is no standard list of application roles. The application requirements will dictate various actors and what operations they need to perform. And, the roles are derived from these actions and requirements. Authorizing methods are normally employed between public access points and requests that the system user could make. Authorization is the security method that should concern application developers, not authentication. Enterprise development has been slow to realize that authentication and authorization are two distinct and separate operations. Within the boundaries of an enterprise network, authentication should only occur once for users of system resources, intranet activity, business applications, common portals, etc. Operating systems, individual servers, web hosts, service providers, etc. would always require authentication and authorization for access to its resources. This scenario is very different from access and priviledge management of application data. This paper is focused specifically with application-level security. It's always the case that each application or product owner wants to protect his application. But, within the walls of a secure enterprise network, the application should only be concerned with privilege or authorization to use its services (what's publically exposed). Proposed Resolution It is proposed that the Client network at the Client Center in Raleigh, North Carolina implement a Single Sign On (SSO) solution using Yale's Central Authentication Service (CAS) and utilize the network Microsoft Active Directory using LDAP as an authentication means thereby using the existing network access identities. In addition to this, create a single configurable Spring servlet filter to verify authorization against the same Active Directory for any hosted JBoss application that does not manage its own user roles. Microsoft applications hosted on IIS do not have to use the proposed system, however, they can easily migrate to this enterprise system and use one of the Microsoft clients with CAS and quickly migrate. This would result in an inexpensive enterprise solution, proven security, and possibly better application performance over the hosting environment. The present IIS reverse proxy can be easily replaced for JBoss by using a single SSO service (CAS) and adding a configured servlet filter and authorization role per URL. Also, CAS is proven for large organizations and clients are provided for Java, Perl, Ruby, .NET, ASP, C#, ColdFusion, etc. Presently, maintenance and implementation are of utmost importance here because the Technical Services group here in the Century Center should not have to program security solutions to a virtually undocumented single sign on (SSO) service. Also, cookies are most commonly maintained on a session basis. The reverse proxy in place on IIS now requires JBoss applications to authenticate repeatedly. This is overkill. The proposed system can adjust in-memory cookie timeouts easily. But, if the authentication system (CAS) is trusting the identity of the application user, the JBoss applications only need to authorize this identified user. The Central Authentication Service (CAS) is very popular and used by many large organizations to provide SSO. Also, CAS is very secure and uses SSL. CAS provides a service manager that allows an administrator to just add the service URL for newly deployed application requiring single sign on and a security proxy call. These secured services will be kept in an Oracle database for presentation link reference. Single Sign On (SSO) SSO or Single Sign On is a quality method that's being employed in Enterprise development to reduce password compromise and to require that application users only need to log in once within a browser session. The SSO concept is very logical, however, it's always been difficult to implement and standards are slow to evolve. The IT folks at Yale University have developed a very popular solution to this problem called CAS. What is CAS? The Central Authentication Service (CAS) is a single server identity management or authentication system that provides an optional in-memory cookie or Single Sign On (SSO) service. CAS provides the ability to securely proxy to protected web applications or services. CAS was originally developed by Yale University and was adopted as a JA-SIG project in December 2004. JA-SIG is a non-profit global consortium consisting of educational institutions and commercial affiliates that promotes solutions to high-level architecture problems. CAS, one of the products they now manage, has now reached final release status and is used to provide a single point of authentication for a federated group of network or internet applications. Why would do I personally recommend CAS? I personally recommend its use because it's successful, highly praised, used internationally, well documented, and it's free. A list of happy customers is provided here. In Production... • Appian Corporation
• Athabasca University
• Azusa Pacific University
• BCcampus
• Bob Jones University
• California Polytechnic Institute
• California State University, Chico
• Campus Crusade for Christ
• Case Western Reserve University
• Columbia
• Darmstadt University of Technology (Germany)
• Dartmouth College
• Employers Direct
• The Evergreen State College
• Florida State University
• GET-INT
• H-E-B Grocery
• Hong Kong University of Science and Technology
• Indiana University
• Instituto Superior Tecnico (Lisbon, Portugal)
• Karlstad University, Sweden
• La Voz de Galicia, Spain
• Memorial University of Newfoundland
• Nagoya University
• NHMCCD
• Northern Arizona University
• Plymouth State University (used with SunGardHE Luminis)
• Pulaski Technical College
• Roskilde University
• Rotterdam University (Hogeschool Rotterdam)
• The Royal Institute of Technology (KTH)
• Rutgers, The State University of New Jersey
• Sabanci University
• SunGard HE Luminis
• Simon Fraser University (Vancouver, B.C.)
• Sony Online Entertainment
• Suffield Academy
• Tollpost Globe AS
• Universidad de Navarra
• Universita degli Studi di Parma
• Universite de Bourgogne - France
• Université de Bretagne Occidentale (Brest) - France
• Universite de La Rochelle, France
• Universite de Pau et des Pays de l'Adour, France
• University of Nancy 1, France
• Universite Nancy 2, France
• Universite Pantheon Sorbonne
• Universiteit van Amsterdam
• University Duisburg-Essen
• University of Arizona
• University of Bristol, England
• University of California, Berkeley
• University of California Merced
• University of California, Riverside
• University of Connecticut
• University of Crete, Greece
• University of Delaware
• University of Geneva
• University of Hawaii
• Uniwersytet Mikolaja Kopernika (Nicolaus Copernicus University)
• Uniwersytet Warszawski
• University of Illinois at Urbana-Champaign - Graduate School Library and Information Science
• University of Kansas Medical Center
• University of Nebraska-Lincoln (Center on Children, Families, and the Law)
• University of New England, Armidale Australia
• University of New Mexico
• University of Rennes1
• University of Saskatchewan
• University of Scranton
• University of Technology, Sydney
• University of Texas at Arlington
• SRCE - University Computing Centre, University of Zagreb (Croatia) English Version
• Uppsala University
• Valtech
• Virginia Tech
• Yale University In Development... • Brigham Young University
• Arizona State University Conclusion This document is in draft status and may be changed. A proper conclusion will be written after the proposal has been reviewed and implementation begins. The Client has the right to disapprove these suggestions and may opt to ignore any problems noted in this document. |
