The present invention relates generally to systems and methods that facilitate code development activities, and more particularly, the present invention relates to a security analysis process wherein security elements of an application are analyzed in view of a current code context in a development environment and developers are provided with feedback indicating security element availability given the current context.
Software development systems provide many tools enabling developers to create applications often consisting of disparate software components. One such situation involves creating applications whereby one or more security considerations may be associated with respective components of the application. For example, many components of an application often contain security permissions that are associated as part of metadata for a file. These security permissions describe what type of access may be granted to a respective file—for example, whether or not read only access is to be given to a file or whether the file should be given read/write access. As can be appreciated, a plurality of such security designations can be declared (e.g., global security rights versus individual sercurity rights).
Presently with current software development tools, it is unclear at the time of development what security elements may be available or unavailable given a current development context. For example, current systems require developers to search through an Application Programming Interface (API) documentation set or to actually deploy and test an application to determine whether a respective API call was permitted within a target development security context. This type of searching is wasteful since it often requires developers to lose time searching for desired security elements or worse—repeat code development operations after determining that desired security functionality is missing. In many cases, the security metadata for a component may not exist in human readable form, in which case the developer can only discover the security requirements through the tedious process of deploying and testing the code in the target security context.
The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.
The present invention relates to systems and methods that facilitate determination and presentation of security components in a code development environment. In one aspect, a security analyzer and interface is provided that displays lists of Application Programming Interfaces (APIs) or other security components that are available to a developer in a particular coding security context such as in a source code editor as the developer edits application code. This can include displaying metadata regarding available APIs, such as brief descriptions of the APIs purpose and parameters accepted by the API. The present invention supplements these displays with code access security metadata for namespaces, classes, and members in managed data assemblies (e.g., Net). Thus, developers can specify a code access security context for their respective application (e.g., the set of permissions the application has), wherein visual or other type feedback is then automatically provided that marks or indicates which APIs are available or unavailable in that security context. In this manner, developers are made aware on the front-end of development which security elements may be missing for an application, and thus can save time associated with discovering at a later time (e.g., during debug) that security components are missing or still required.
In general, developers and other IT professionals can select between a number of competing platforms for building rich, secure client applications for desktop applications. Thus, the quality of tools for a platform is an important factor that should be addressed when supplying tools for the platform. The present invention provides a model for Partial Trust Applications that enables developers to quickly and easily understand/determine which APIs (or other security components) are available for their application which runs under a particular security context, and which APIs may require additional permissions. The subject invention makes it easy to develop applications that function correctly in restricted security contexts by enabling developers to identify potential security issues (e.g., via a user interface highlighting such issues) as they are writing code rather than discovering the problems later on as they debug the application.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the invention are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the invention may be practiced, all of which are intended to be covered by the present invention. Other advantages and novel features of the invention may become apparent from the following detailed description of the invention when considered in conjunction with the drawings.
The present invention provides an extensible mechanism for highlighting and displaying security components or elements that are to be employed for a given application context. In one aspect, a system is provided for computerized code development environments. The system includes a data source that stores one or more application components (e.g., application files residing in a database that are employed to construct an application). A security component automatically analyzes the application components with respect to security information associated with the application components (e.g., XML security metadata associated with the application components). A feedback component then provides information related to a given development security context (e.g., declared by a developer via a development tool) in view of the security information. For example, a code developer may declare an application having various disparate software components or files that cooperate to form a desired application under development. The developer, in the context of declaring the application components can specify desired security configurations for the application or target. When the application components are retrieved from the data source, the feedback component provides a listing or other type output indicating which security information may be available or unavailable given the development security context. In this manner, missing security elements can be accounted for before applications are actually built and run which provides appreciable time savings over previous systems.
As used in this application, the terms “component,” “model,” “system,” “analyzer,” “object,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
Referring initially to
In general, the security analyzer 140 determines which security elements may be available or unavailable given a security context defined by the developer at 130. This can include automatic creation of a security file 170 that indicates current security considerations for the application components 150. For example, the security analyzer 140 can determine available security permissions for the components 150. Based upon the security declarations at 130, and the security file 170, the tool 110 generates feedback 180 to the security output interface 120 that provides indications of the types of security that may be available or unavailable for the application under development by the tool 110. For example, the security output interface 120 can display lists of application components 150 such as Application Programming Interfaces (APIs) or other security components that are available to a developer in a particular coding security context such as in a source code editor (not shown) at the tool 110 as the developer edits application code. This can include displaying metadata regarding available APIs, such as brief descriptions of the APIs purpose and parameters accepted by the API. The system 100 supplements these displays with code access security metadata for namespaces, classes, and members in managed data assemblies (e.g., Net). It is noted that managed assemblies and classes are generally associated with a managed code environment having a garbage collector or other component for automatically managing object lifetimes.
Developers can specify a code access security context for their respective application (e.g., the set of permissions the application has) at 130, wherein visual or other type feedback 180 is then automatically provided that marks or indicates which APIs or components are unavailable in that security context. In this manner, developers are made aware on the front-end of development which security elements may be missing for an application, and thus can save time associated with discovering at a later time (e.g., during debug) that security components are missing or still required.
It is noted that the security output interface 120 can be provided as a Graphical User Interface (GUI). For example, the interface 120 can include one or more display objects (e.g., display icon) that can include such aspects as configurable icons, buttons, sliders, input boxes, selection options, menus, tabs and so forth having multiple configurable dimensions, shapes, colors, text, data and sounds to facilitate operations with the systems described herein. In addition, user inputs (e.g., supplied with the tool 110) can include a plurality of other inputs or controls for adjusting and configuring one or more aspects of the present invention. This can include receiving user commands from a mouse, keyboard, speech input, web site, browser, remote web service and/or other device such as a microphone, camera or video input to affect or modify operations of the various components described herein.
Referring now to
Upon observing the security output 200, a developer can be instructed that other security items should be added before constructing or building a respective application. In one example, if the developer highlights or selects components designated as currently unavailable, a tool tip or other interface can pop-up and display possible remedies such as providing an alternative path for selecting the currently unavailable security component. As can be appreciated, there can be a plurality of different techniques for designating available and/or unavailable security components or files. As will be described in more detail with respect to
Turning to
Some benefits of XML document comments having associated security metadata can include:
Easy Reuse Across Tools and Languages.
The metadata is stored as XML, making it open to any tool that desires to read the metadata.
3rd Parties Library Vendors can Participate.
Third parties can easily generate the XML document comment files for their assemblies, thereby providing rich tool support around their class libraries.
Potential for Community Participation.
Developers can write custom type editors and debugger visualizers that can be plugged into development tools simply by modifying the XML. This can include defining additional metadata sections, such as best practices, additional documentation, and so forth along with tools and add-ins that leverage this metadata.
Little or no Impact on Current System Performance and Working Set.
Since XML document comments are typically stored in separate files from actual assemblies, it is possible for applications to load assemblies without automatically incurring the cost of loading the associated design time metadata.
Metadata can be Added or Modified Without Rebuilding the Assembly.
This makes it possible to retrofit metadata onto previously shipped assemblies. It thus may be easier to fix bugs in metadata. It can also empower users to add metadata to assemblies they cannot build themselves, or even correct errors in existing metadata.
Metadata can be Owned by Tools as Appropriate.
The process of generating XML document comments is quite flexible, allowing metadata to be defined and merged from multiple sources. Flexible ownership allows tools to mitigate dependencies on component owners where necessary or appropriate.
Proceeding to 710, a security context is defined. As noted above, this is usually determined by a developer during design of an application employing commercially available software development tools. At 720, respective security components are analyzed for an application under development. For example, this can include analyzing security metadata such as a permission set for the respective components of the application. At 730, the security components are compared to the given security context to determine whether the respective security component is available for the given security context at 740. At 750, security output is generated indicating which security components are available for the given context (if any) and which security components are unavailable for the given context (if any). As noted above, substantially any type of audio or visual feedback can be employed to indicate available and/or unavailable security components (e.g., highlight available and de-emphasize unavailable).
With reference to
The system bus 818 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 11-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 816 includes volatile memory 820 and nonvolatile memory 822. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 812, such as during start-up, is stored in nonvolatile memory 822. By way of illustration, and not limitation, nonvolatile memory 822 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 820 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 812 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 812 through input device(s) 836. Input devices 836 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 814 through the system bus 818 via interface port(s) 838. Interface port(s) 838 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 840 use some of the same type of ports as input device(s) 836. Thus, for example, a USB port may be used to provide input to computer 812, and to output information from computer 812 to an output device 840. Output adapter 842 is provided to illustrate that there are some output devices 840 like monitors, speakers, and printers, among other output devices 840, that require special adapters. The output adapters 842 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 840 and the system bus 818. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 844.
Computer 812 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 844. The remote computer(s) 844 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 812. For purposes of brevity, only a memory storage device 846 is illustrated with remote computer(s) 844. Remote computer(s) 844 is logically connected to computer 812 through a network interface 848 and then physically connected via communication connection 850. Network interface 848 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 1102.3, Token Ring/IEEE 1102.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 850 refers to the hardware/software employed to connect the network interface 848 to the bus 818. While communication connection 850 is shown for illustrative clarity inside computer 812, it can also be external to computer 812. The hardware/software necessary for connection to the network interface 848 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the. present invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.