System and method for providing java server page security

A system and method for providing Java Server Page (JSP) security are provided. In one embodiment, a method for providing JSP security comprises selecting a JSP file at least partially in response to a request by a user. The request includes information identifying the user. A security tag associated with at least a portion of the JSP file is located for the selected JSP file. Authorization of the user to access the portion of the JSP file is determined based on the security tag. At least one web page is generated based, at least in part, on the determination.

TECHNICAL FIELD

This disclosure relates generally to the field of networking and more particularly to a system and method for providing Java Server Page (JSP) security.

BACKGROUND

The growth of the Internet has led to the development of many platforms for creating dynamically-generated content accessible through web browsers. Each of these platforms provides a variety of tools and/or Application Program Interface (API) calls to support the development of dynamic web sites. For example, Java Server Page (JSP) is one of the more widespread technology for developing dynamically-generated web pages in web-based applications. JSP utilizes tag-based scripts to separate business logic from display logic.

SUMMARY

A system and method for providing Java Server Page (JSP) security are provided. In one embodiment, a method for providing JSP security comprises identifying a JSP file at least partially in response to a request by a user. The request includes information identifying the user. A security tag associated with at least a portion of the JSP file is located for the identified JSP file. Authorization of the user to access the portion of the JSP file is determined based on the security tag. At least one web page is generated based, at least in part, on the determination. The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Particular features, objects, and advantages of the disclosure will be apparent from the description and drawings and from the claims.

DESCRIPTION OF EXAMPLE EMBODIMENTS

FIG. 1illustrates one embodiment of a system100for providing Java Server Page (JSP) security. At a high level, system100is a client/server environment comprising a plurality of clients112a-cand at least partially secure server114, but may also be a standard computing environment or any other suitable environment. For example, illustrated system100may be a portion of an enterprise security system that allows server114to grant or deny a client112access to a JSP file or portions of a JSP file according to a user's resource privileges. In general, system100secures portions of a JSP file through embedded security tags. As a result of these security tags, system100may reduce, minimize, or eliminate unauthorized accessing and viewing of information, such as business information. Additionally, using associated security tags, system100may present client112with a customized interface via network116.

Network116facilitates wireless and/or wireline communication between network devices. Network116may include one or more Local Area Networks (LANs), Radio Access Networks (RANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), all or a portion of the global network known as the Internet, and/or any other communication system or systems at one or more locations. Network116may communicate, for example, Internet Protocol (IP) packets, Frame-Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. In certain embodiments, system100may generate requests and/or responses and communicate them to a workstation, server, or other computer systems located in network103such as, for example, client112.

Client112is typically a computer that requests and receives services and information from server114via network116. It will be understood that there may be any number of clients112coupled to server114or, alternatively, client112may comprise a management component of server114. A user of client112may use client112for accessing JSP files. In general, client112may include input devices, output devices, mass-storage media, processors, memory, interfaces, communication ports, or other suitable components for communicating client requests117to server114and receiving responses via network116, such as server responses119. In one embodiment, client request117comprises a Uniform Resource Locator (URL) including a file name with a “.jsp” extension. As used in this document, client112is intended to encompass a personal computer, a work station, network computer, kiosk, wireless data port, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device. The present disclosure contemplates computers other than general purpose computers as well as computers without conventional operation systems. As used in this document, the term “computer” is intended to encompass a personal computer, workstation, network computer, or any other suitable processing. For example, client112may comprise a computer that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with the operation of server114or clients112, including digital data, visual information, or any other suitable information. Both the input device and output device may include fixed or removable storage media such as magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of client112through a portion of a data display, namely GUI118.

GUI118comprises a graphical user interface operable to allow the user of client112to interface with system100to request and receive dynamically or otherwise generated web pages. The term “dynamically” as used herein, generally means that the appropriate processing is determined at run-time based upon the appropriate information. Generally, GUI118provides the user of client112with an efficient and user-friendly presentation of data provided by system100, such as charts and tables. GUI118may comprise a plurality of displays having interactive fields, pull-down lists, and buttons operated by the user. It should be understood that the term “graphical user interface” may be used in the singular or in the plural to describe one or more graphic user interfaces in each of the displays of a particular graphical user interface. Further, GUI118contemplates any graphical user interface, such as a generic web browser, that processes information in system100and efficiently presents the information to the user. Server114can accept data from client112via the web browser (e.g., Microsoft Internet Explorer or Netscape Navigator) and return the appropriate Hyper Text Markup Language (HTML) or eXtensible Markup Language (XML) responses.

Server114is typically a computer that receives request for services and information from clients112and communicates responses to these request. In the illustrated embodiment, server114includes network interface122, processor125and memory124and comprises an electronic computing device operable to receive, transmit, process and store data associated with system100. AlthoughFIG. 1provides one example of server114that may be used with the disclosure, server114can be implemented using computers other than servers, as well as a server pool. For example, server114may comprise a general-purpose personal computer (PC) a Macintosh, a workstation, a UNIX-based computer, a server computer, or any other suitable device. According to one embodiment, server114may comprise a web server. Server114may be adapted to execute any operating system including UNIX, Linux, Windows, or any other suitable operating system. In short, server114may comprise software and/or hardware in any combination suitable to provide secured access to JSP files or portions of JSP files to client112. For example, server114may grant or deny access to portions of a JSP file based on resource privileges associated with the user of client112.

Server114includes interface122for communicating with other computer systems, such as client112, over network116in a client-server or other distributed environment. In certain embodiments, server114receives JSP files from network116for storage in memory124. Generally, interface122comprises logic encoded in software and/or hardware and a suitable combination and operable to communicate with network116. More specifically, interface122may comprise software supporting one or more communications protocols associated with communication network116or hardware operable to receive and transmit physical signals encoding request for and responses regarding information stored in memory124.

Memory124may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, Random Access Memory (RAM), Read Only Memory (ROM), removable media, or any other suitable local or remote memory component. In this embodiment, memory124includes database128, Application Program Interface (API)130, a security servlet136, a JSP servlet135, and JSP files133, but may also include any other appropriate files. Database128comprises any storage media for the storage and retrieval of information. According to one embodiment, database128may comprise a relational database normally accessed through Structured Query Language (SQL) statements. Server114may then invoke Java Database Connectivity (JDBC) to enable Java programs to execute SQL statements, allowing Java programs to interact with any SQL-compliant database. Alternatively, database128may comprise XML documents, flat files, or Comma-Separated-Value (CSV) files. In the illustrated embodiment, database128includes a plurality of access control lists140and a plurality of role profiles146, but may include any other data, as appropriate.

Access control list140comprises any rules, instructions, algorithms any other directives used by server114to determine what role profiles146are associated with an identified client112. Server114may identify a client112based on any appropriate characteristic such as, for example, a selection by client112or a user group, user identification (ID), password, IP address, logical location, or any suitable characteristic of client112. Furthermore, the client112may be directly identified or otherwise associated with role profiles146. Access control list140may be any suitable format such as, for example, an XML document, a flat file, CSV file, a name-value pair file, SQL table, or others. In one embodiment, access control list140comprises an encrypted table including a plurality roles142. Access control list140may be created or modified by client112, server114, a third-party software vendor, or any other appropriate user or computer in system100, loaded from a default access control list, or received via network116. In summary, access control list140comprises any file including roles142associated with client112and operable to be processed by server114.

Role142indicates what roles or positions are associated with client112and thus the role profiles146that are associated with access control list140. Roles142may be of any appropriate data type, including float, integer, currency, date, decimal, string, or any other numeric or non-numeric format that indicates what profiles146should be retrieved from database128. Further, each role142may comprise a file name, a memory address, URL, or any other suitable basis for determining a corresponding profile146. In general, a role142may be associated with a user of client112and provide a basis for determining privileges that role142has with respect to a resource. For example, role142may indicate that client112has an administrative role of server114and identifies a corresponding role profile146. Alternatively, role142may be other suitable roles such as, for example, a browsing role, customer role, vendor role, manager role, where each identify a corresponding role profile146.

Role profile146comprises rules, instructions, algorithms, or any other directive used by server114to determine what resources an associated role142may access. A resource is information and/or a service provided by server114or other component of system100. For example, a resource may include accounting information, administrative information, billing information, security data, management information, queue management services, administrative access. In the illustrated embodiment, a portion of JSP file133comprises a resource. Server114may associate role profile146and role142based on a selection by user of server114, a selection received via network116, a default selection, results of processing occurring at server114, or any other suitable process. Role profile146may be any suitable format such as, for example, an XML document, a flat file, CSV file, a name-value pair file, SQL table, or others. In one embodiment, role profile146includes resource privileges148. Role profile146may be created, modified, or supplied by client112, server114, a third-party software vendor, or any appropriate user of any computer in system100, loaded from a default profile, or received via network116.

Resource privilege148indicates whether an associated role142has privileges with a corresponding resource. In other words, server114grants or denies access to a resource based on a corresponding resource privilege148. It will be understood that the absence of a resource privilege148from role profile146may indicate that the associated role142does or does not have privileges with the corresponding resource. Resource privilege148may be any appropriate data type, including float, integer, currency, date, decimal, string, or any other numeric or non-numeric format. For example, resource privilege148may include any suitable indicators that server114uses to grant or deny access to a resource.

Returning to memory124, security API130comprises a conventional application program interface and may include class definitions for security management. In general, API130includes a set of routines, protocols, and/or tools used to generate programs. API130may comprise a file, script, executable, template or any other suitable description such that server114may generate security servlet136. API130may be created or supplied by server114, a third party, or any other suitable user of system100. API130may be invoked from any suitable Java class including servlets, struts action classes, enterprise Java beans, and other suitable Java-based or Java-compatible classes. In one embodiment, API130includes either source code for class definitions written in or an executable code for class definitions based on any appropriate language such as, for example, C, C++, Java, Perl, and others. The class definitions are used to specify security management functions for security servlet136. For example, security management functions may include verifying a user ID and password or determining privileges that a user ID has with respect to a resource based on roles associated with the user. For example, API130may comprise the following methods using corresponding parameters. The method “init” may initialize a user name and password. The method “doAuthentication” may be used to authenticate login of client112. The method “doAuthorization” may be used to check a user's access privileges. The method “loadUserACL” may load a user's access control list (ACL)140. The method “addUser” may add a new user. The method “addUser” may associate a user with new roles. The method “static void addUserRoles” may add a new role. The method “addRole” may associate roles with resources. The method “addRoleResources” may add a new resource. The method “addResource” may delete a user. The method “deleteUser” may remove roles from a user's role list. The method “deleteUserRoles” may delete a role. The method “deleteRole” may remove resources from role's resource list. The method “deleteRoleResources” may delete a resource. The method “deleteResource” may load list of resources from a flat file. The method “loadResourcesFromFile” may save the list of resources information to a flat file. The method “saveResourcesToFile” may change user's login password. The method “changePassword” may change a user's password. It will be understood that the example methods are for illustration purposes only. API130may comprise any logic operable to be invoked by server114to generate security servlet136and include none, some, or all of the illustrated methods as well as additional methods not illustrated.

Based on API130class definitions, API130may generate security servlet136. Security servlet136comprises any software component operable to perform one or more security management functions such as filter-based authentication and role-based authorization. In certain embodiments, servlet136may be a server-side program based on a class defined in API130and written or based on any appropriate object-oriented programming language. In one embodiment, security servlet136is operable to receive parameters, invoke calls to database128, perform security functions based on the received parameters, receive responses from database128, and pass the results of the performed security functions to JSP servlet135. Security servlet136may invoke JDBC to query database128. In one embodiment, security servlet136compares the at least one resource privilege148to the received parameters to determine whether a user of client112is granted or denied access to JSP file133or a portion of JSP file133. Security servlet136may also perform additional security management functions such as those listed above.

JSP file133is associated with one or more dynamic or otherwise web pages based, in part, on an identity of the user of client112. JSP file133may comprise a text file that uses tags and scripts written in Java to generate the page content in response to a client request117. It will be understood that JSP file133may alternatively be scripted with Java-based code, Java-compatible code, or code performing Java-like functions. The tags that may be included in JSP file133included HTML tags, XML tags, JSP tags, or other suitable tags. The HTML and/or XML tags may be associated with the page design and static content of the page, while the JSP tags and Java code comprise the logic used to generate the dynamic or otherwise web pages. For example, a JSP file133may be used to represent data in a tree/hierarchical structure. In this example, a node in the tree can be presented on the JSP page with text, icon, and folder status tabs and operable to be displayed with options such as links and menus. An exemplary JSP file133that provides such features and functions may include the following exemplary scripts:

JSP file133may be created or modified by server114, a third-party software vendor, or any other suitable user of any computer in system100. JSP file133may also be loaded from a default file or received via interface122. JSP file133may be noted by the extension “.jsp” or any other suitable extension. In one embodiment, JSP file133includes at least one security tag134associated with a portion of JSP file133. Alternatively, security tag134may be located outside the file (not illustrated) and otherwise associate with the portion. In this embodiment, security tag134is a JSP tag but may alternatively be a JSP-based tag, JSP-compatible tag, or any other suitable command inserted in a file. Security tag134may include an embedded resource descriptor or ID that associates the security-tagged portion of JSP file133with a resource. For example, the following exemplary script includes an example security tag134that identifies a resource ID with the parameter ‘resource’:

Based on JSP file133, server114automatically compiles JSP file133into JSP servlet135in response to an initial client request117for JSP file133. The term “automatically” as used herein, generally means that the appropriate processing is substantially performed by some component of system100. JSP servlet135comprises any software component operable to receive and process HTTP request, perform the Java-based logic embedded in JSP file133, and generate the dynamic or otherwise pages. In one embodiment, JSP servlet135comprises an executable Java class file. JSP servlet135may be based, at least in part, on classes written Java, Java-based, and Java-compatible languages. JSP servlet135may be further operable to pass parameters (e.g., embedded resource ID, user ID, etc.) to and receive response from security servlet136. Based on these responses, JSP servlet135may grant or deny access to a portion of a requested JSP file133associated with security tag134. For example, JSP servlet135may transmit client response119including a dynamically generated web page to client112that excludes HTML associated with the security tag. It will be understood that while JSP servlet135, API130, security servlet136are illustrated as separate modules, JSP servlet135, API130and security servlet136may comprise a child or submodule of another software module without departing from the scope of this disclosure.

Processor125executes instructions and manipulates data to perform operations of server114. AlthoughFIG. 1illustrates a single processor125in server114, multiple processors125may be used according to particular needs, and referenced to processor125is meant to include multiple processors125where appropriate. In the illustrated embodiment, processor125includes or executes JSP engine126. JSP engine126may receive requests117and processes JSP file133. Regarding the illustrated embodiment, JSP engine126receives and decodes client request117for JSP file133associated with a dynamic web page. In response to a client request117, JSP engine126may compile the requested JSP file133. JSP engine126may include any hardware, software, firmware, or combination thereof operable to receive client request117and compile JSP file113. It would be understood that JSP engine126is illustrated as a single multi-task module, but the features and functionality performed by this engine may be performed by multiple modules.

In one aspect of operation, API130generates security servlet136based on instructions received from server114or network116. A user of client112transmits a client request117including a request for a JSP file133to server114via network116. Client request117may additionally include a user ID and password. JSP engine126receives and decodes the client request117. If the request JSP file133has not been compiled, JSP engine126parses out the Java code and JSP tags from the requested JSP file133to generate an executable JSP servlet135, which is operable to receive client request117.

During execution of JSP servlet135, JSP servlet135invokes security servlet136and passes parameters including, for example, resource IDs, user ID, password, or other suitable information to security servlet136. Based, in part, on the user ID, security servlet136invokes JDBC to query database128to retrieve an access control list140, including roles142associated with the user ID. Based upon the retrieved roles140, security servlet136again invokes JDBC to query database128to retrieve role profiles146associated with each retrieved role140. Once role profiles146including resource privileges148are retrieved, security servlet136compares the resource ID embedded in security tag134with the retrieved resource privileges148. Referring to the example security tag134illustrated above, the resource ID was “hello-world.” In this example, security servlet136compares the resource ID ‘hello-world’ with the retrieved resource privileges148. Based on this comparison, security servlet136may grant or deny the user of client112access to the portion of the JSP file133associated with the security tag134. Referring to the example, if security servlet136determines that the resource ID is included in or identified by resource privilege148, then security servlet136may return a ‘TRUE’ to JSP servlet135. Based on this status, JSP servlet135transmits the HTML to client112. Otherwise, security servlet136returns ‘False’ to JSP servlet135that, based on this status, denies access to the illustrated HTML. Once this determination is made, a web page is dynamically generated that may or may not include the portion of JSP file133associated with security tag134, and the web page is transmitted to client112.

FIG. 2illustrates one embodiment of a database schema200that may be accessed by security servlet136. Using this database schema, both filter-based authentication and role-based authorization may be provided. Referring toFIG. 2, database schema200includes user-role202, user204, role206, resource208and role-resource210. The associations between components are illustrated by links212. User-role202stores a user-id and at least one role-name associated with the user-id. As illustrated, user-role202may comprise access control list140. User204is associated with user-role202via link212aand stores a full name and password associated with the user-id. User204may be queried by security servlet136or another processor to provide login-based security. Role206is associated with user-role202via link212band stores a description of the role-name. Resource208stores a resource-name and resource associated with the resource-id. Role-resource210is associated with user-role202via212cand212band resource208via212d. Role-resource ID is associated with the role-name. As illustrated, role-resource210may comprise role profile146, which may be queried by security servlet136to provide role-based user security management. It will be understood that the various components of the illustrated schema200may be combined or omitted additional components may be added according to particular needs, and such components may comprise multiple components. Additionally, the illustrated schema may be implemented using the example methods of API130listed above. It will be understood that these are only exemplary data schema and class definitions and other features and functions may be implemented without varying from the scope of this disclosure.

FIG. 3is an exemplary flow diagram illustrating a method300for providing JSP security. Method300is described with respect to security system100ofFIG. 1, but method300could also be used by any other system. Moreover, system100may use any other suitable technique for performing these tasks. Thus, many of the steps in this flowchart may take place simultaneously and/or in different orders as shown. Moreover, system100may use methods with additional steps, fewer steps, and/or different steps, so long as the methods remained appropriate.

Method300begins at step302where server114generates a security servlet136based on a request received by a user of server114or network116. Next, at step304, server114receives a client request117for a JSP file133. The client request may include a user ID and password. JSP file133includes at least one portion of JSP file133associated with security tag134which includes an embedded resource ID. At decisional step306, JSP engine126determines if the request JSP file133has been compiled. If JSP file133has not been compiled, then JSP engine126parses the JSP tags and Java code from JSP file133to generate JSP servlet135at step308. If JSP file133has been compiled, then the execution proceeds to decisional step310. At decisional step310, if the user of client112is denied access to JSP file repository132, then JSP engine126transmits a denial of access to client112at step312. At decisional step314, if the user of client112declines to add a new user of server114, then the execution ends. For example, security servlet136may query user204illustrated inFIG. 2to compare the received user ID and password with those stored in user204. If the user of client112agrees to add a new user of server114, then server114requests user information including user ID, password, or other suitable information at step316. At step318, access control list140is generated and associated with the new user ID and includes a list of roles142. At decisional step320, if the new user declines to renew the request for JSP file133, then execution ends. If the new user renews request for JSP file133, then execution proceeds to step322. At step322, JSP engine126executes JSP servlet135. At step324, JSP servlet135extracts embedded resource ID from security tag134and user ID from client request117. For example, the resource ID may comprise “account-numbers” indicating the requested resource is associated with accounting and the user ID may comprise “USER1.”

Security servlet136loads access control list140including roles142associated with the user ID at step326Referring to the example, security servlet136loads an access control list140associated with “USER1” and including roles142“Accounting” and “Human Resources” indicating that “USER1” has both accounting and human resources roles. Next at step328, security servlet136loads role profiles146with corresponding resource privileges148associated with the retrieved roles142. Continuing to refer to the example, security servlet136retrieves resource privileges148associated with the “Accounting” and “Human Resources” roles such as, for example, “account-numbers,” “employees”, or other suitable resource privileges148for each role142associated with “USER1.” At decisional step330, security servlet136compares the embedded resource ID to the retrieved resource privileges148to grant or deny access to the portion of the JSP file133associated with the security tag134. In the example, security servlet136compares the resource ID “account-numbers” with the retrieved resource privileges148, which includes “account-numbers,” so security servlet136may communicate “TRUE” status to JSP servlet135. If access is granted, then, at step332, JSP servlet135dynamically generates HTML based on the entire JSP file133. Based on the resource ID matching a retrieved resource privilege148, JSP servlet135generates HTML based on JSP file133. If the user is denied access to the tagged portion of the JSP file133, then, at step334, JSP servlet135dynamically generates HTML based on the rest of JSP file133not associated with security tag134. At step336, JSP servlet135communicates the HTML to client112.