Security Architecture This article details the Movable Feast Security Architecture and philosophy. The purpose of this document is to explain how the Movable Feast software system satisfies the security requirements that allow this information system to be used in places where high confidentiality protection levels are needed. The first discussion briefly states the Movable Feast security architecture by discussing its goals and capabilities. Following this description of Movable Feast, there will be brief discussion of the Certification and Accreditation Process and the documents that are used to guide this process. Finally, we review the six basic security requirements that lead to the realization of what it means to call a computer system "secure." What is Movable Feast This section defines Movable Feast, the goals of the security architecture and the overall requirements for security. Movable Feast is an analytic tool for retrieval, manipulation and sharing of information. Using a variety of interfaces, a user retrieves relevant data from multiple databases that are either housed by Movable Feast or externally located. Data Analysts review data in a variety of ways including web pages, web services and workflow. Analysts view geospatial data through a map interface. Analysts may define complex data access through the workflow interface and organize the data through a workspace. The system allows the sharing of the definitions of workflows in a collaborative workspace. The resulting data from running a collaborated workflow, however, is never shared. The use of a thin client architecture allows Movable Feast to change without redeploying the application to individual users. All access to Movable Feast, whether client or server, web or web services, is encrypted. Movable Feast Software Movable Feast exclusively uses open standards software. Movable Feast uses a JEE server in conjunction with Lucene and Jena as dependent jar files. The open standard custom software integrates with the open standards tools to provide an enterprise solution. Movable Feast runs with any ANSI-99 compliant relational database. DCID 6/3 and the ORANGE Book Information system security certification and accreditation is a major part of the risk management process at DoD Intelligence Agencies. These agencies use the DoD and Intelligence Community certification and accreditation policies in similar manners. The process implements structured, life cycle, system engineering approach to certification and accreditation that is described in DoD Directive 5200.40. As part of this process, Director of Central Intelligence Directive 6/3 (DCID-6/3) entitled, “Protecting Sensitive Compartmented Information Within Information Systems”, provides the criteria under which each information system is judged. In order to be certified and accredited, each system must satisfy a set of requirements for confidentiality protection level and levels of concern for integrity and availability. These requirements include both security functionality and the evidence needed to certify and accredit the system. Goal and Outline of the Security Plan A common question asked when working with web architectures is, "How do you secure an entire web architecture?" followed, skeptically, by the statement: "Currently we cannot secure Web services, but we can secure the client web application” Movable Feast is an implementation of an architecture that ensures a secure solution irrespective of the type of access (web browser or web services). Requirements for Security First, we will consider traditional methods of providing authentication, authorization and confidentiality using http and the associated problems. We will then present our unique solution, Movable Feast. Movable Feast Security Characteristics The client access to Movable Feast requires no knowledge of the target environment. Our solution is elegant and implementation agnostic. Movable Feast has a security capability that demonstrates how JEE provides confidentiality, authentication and access control. These mechanisms are available to arbitrate access irrespective of the access mechanism, i.e. the web, enterprise beans, or web services. The following characteristics describe Movable Feast: The application will run on any web browser, web server, or EJB server The smallest configuration changes are required to move from EJB server to EJB Server JEE is the host and target environment The objectives for Movable Feast are: To maximize the use of definitional constructs while minimizing the amount of written software To maximize the portability across all platforms while minimizing software changes To maximize the use of generalized constructs that are typical of EJB development The same JAAS/Login module is used for two-way SSL from a browser or web service First, let us consider what we are trying to achieve with Web Security. According to W3C the following are six important security considerations for a comprehensive security framework: Six Important Security Considerations (W3C) Authentication guarantees that the service is accessible for anyone with a verified identity Authorization guarantees that the authenticated person has the right to access the service or data Confidentiality guarantees that the data passed between the requester and provider is protected from eavesdroppers Integrity offers that the message was not modified in its path from requestor to provider Non-repudiation guarantees that the sender of the message cannot deny that he/she sent it at a later point in time Accessibility ensures that the service is always accessible and that it is not impaired by attacks, like denial-of-service (DOS), from outside or inside of the system hosting the service Movable Feast offers solutions for authentication, authorization and confidentiality. Identity management in conjunction with the internet security model offers Non-repudiation, with routers and network infrastructures handling Accessibility and Integrity. Using a solid network infrastructure with Movable Feast software offers a total multi-level security architecture. Our first consideration is the traditional, http provision of authentication, authorization and confidentiality followed by a discussion of the problems associated with these solution types. Finally, we will solve the security problems discussed by introducing a more secure interface. We will use JEE as the target environments for this solution with one caveat. The client access to the server requires no knowledge of the target environment. This means that our solution is implementation agnostic. Traditional HTTP Security Traditionally we secured http access by using the following: HTTP basic authorization HTTPS (HTTP Secure) or HTTP with secure socket layer (SSL) HTTP authorization + HTTPS However, HTTP security does not address all of the Web services security guidelines, listed earlier. The best possible configuration is to use HTTPS with HTTP authorization, which gives us authentication, authorization and confidentiality and the HTTP layer. The question to consider is if we use Enterprise Beans for our business logic, how do we secure the accesses at the HTTP and EJB layers? Traditional HTTP Authorization HTTP provides authorization (BASIC-AUTH, CLIENT_CERT) as simple mechanism defined in the web.xml file for a web application. Using this mechanism we can protect Web resources from unauthorized access. To access resources protected using HTTP BASIC-AUTH, a user has to provide a username and password. To access resources protected using HTTP CLIENT_CERT the browser provides a certificate. CLIENT_CERT includes a client certificate as a requirement for access instead of a username password pair. Now that we have given access authentication and authorization at the web layer, how do we provide confidentiality and secure our business logic? Also, how do we give similar access for web services? Traditional HTTP Authentication: HTTPS Secure socket layer (SSL) is a technology which allows Web browsers and Web servers to communicate over a secured connection. This means that the data being sent are encrypted by one side, transmitted, and decrypted by the other side before processing. This is a two-way process, meaning that both the server and the browser encrypt all traffic before sending out data. The trusted store provides the handshaking between the browser and the http server allowing encrypted communication. Using JEE as our target environment, we turn on single sign on which assures us of single authentication irrespective of how many different web applications a user accesses. This is traditional web security with some extensions added to prepare us for full container security. JEE : Enterprise JavaBeans Technology Securing Enterprise Java Beans (EJBs) Enterprise JavaBeans (EJB) technology is the server-side component architecture for the Java 2 Platform, Enterprise Edition (JEE) platform. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology. To secure an Enterprise Bean, we would like to leverage the roles used at the web layer and provide the same type of role based security just at the EJB method. To do this we write a custom JAAS login module and use a custom principal. Writing the Login Module and Principal Finally, it is not hard to write a login module. They are typically 50 to 100 lines in modules. Prior to open standards, advanced security would require the writing of hundreds if not thousands of lines of software. Using JEE and JAAS most of our work was in the definitions contained in the XML files. Service Oriented Architecture Service Oriented Architecture (SOA) is a very broad way to describe a group of services working together to solve a problem or group of problems. Not all SOA’s are the same. The Team chose a group of technologies that works well together and provides MoveableFeast the security and flexibility required to bring this project through a successful production transition. Breaking the components down, it looks relatively simple. At the operating system level Ubuntu Linux are utilized. Ubuntu provides a very solid Debian based Linux stack that provides all the components needed to insure a secure easily updated environment that can run any open source technology. MySQL is used to handle the database back end needs. MySQL is a best of breed open source relational Database that, again, provides a secure and flexible data storage option. Apache2 provides a tried and true web server that is accepted and utilized in several industries. JBoss Application Server provides another open source offering that has become a paragon of middleware technologies. JBoss, in combination with RichFaces and JBoss Seam, provides a unique ability to rapidly develop and deploy user friendly front ends to access and manipulate back end data. Security of the SOA provides a very valuable asset and is paramount to the success of this project. Architectures of this very nature have been certified as PL3+ Compliant and survived intrusion detection testing for said certifications. This provides the opportunity to focus efforts on solving business problems outside of security concerns. The client access to MoveableFeast requires no knowledge of the target environment. The solution is elegant and implementation agnostic. MoveableFeast has a security capability that demonstrates how JEE provides confidentiality, authentication and access control. These mechanisms are available to arbitrate access irrespective of the access mechanism, i.e. the web, enterprise beans, or web services. The following characteristics describe MoveableFeast: The application will run on any web browser, web server, or EJB server. The smallest configuration changes are required to move from EJB server to EJB Server. JEE is the host and target environment. The objectives for Movable Feast are: To maximize the use of definitional constructs while minimizing the amount of written software. To maximize the portability across all platforms while minimizing software changes. To maximize the use of generalized constructs that are typical of EJB development. The same JAAS/Login module can be used for two-way SSL from a browser or web service. Rest and SOAP Web Services REST Representational State Transfer, or REST, in general is a group of networking architectural principles that are used to determine the naming and addressing of resources. REST web services uses HTTP to transfer data without an additional protocol such as SOAP. MoveableFeast accomplishes RESTful interactions by the SEAM application handling RESTful URL's via a Url Rewrite Filter and through a RESTFul web service application. Some of the proposed advantages of using RESTful applications include: Improved response time and reduced server load. Reducing reliance on session state information. Browser accessible. Technology agnostic. SOAP Simple Object Access Protocol, or SOAP, specifies a protocol for exchanging data through web services over networks. Extensible Markup Language, or XML, is the data format and is usually coupled with Remote Procedure Call, or RPC, and HTTP for communications. This directional XML communication can pass data between applications to be interpreted and displayed in any format needed by the end user. System Integration MoveableFeast allows outside vendors and systems to integrate with the SOA in three different areas: Web Layer, Application Layer and EJB Layer. Web Layer MoveableFeast's Application Login creation interface provides an avenue to connect to an outside web based solution. By providing authentication parameters and URL access to the outside application, administrators can provide an automatically authenticated access link to the outside vendor’s web solution. Application Layer MoveableFeast can incorporate existing solutions within the flexible architecture, by installing other SOA based solutions and configuring the applications to seamlessly integrate into the SOA. MoveableFeast's code base can also be extended to access other webservice and webservice type connections to outside data sources. EJB Layer MoveableFeast can marshal access to outside data sources and representations via EJB creation and extensions to the SOA code base. The EJB's can then push data to a view in the web layer allowing for data interaction. Data Adjudication We adjudicate data on a per triple basis using provenance and functional properties. A class, called Provenance, uses an Object Property to relate every triple to its corresponding source. The Provenance class contains security markings, the original source document, who provided the data, when it was provided and the certainty the data is correct.