The field relates to web application security. More precisely, the field relates to a unified framework for authentication, authorization, and session management.
Some web applications do not provide authentication and authorization out-of-the-box. A common suggested strategy for building authentication and authorization is to install a set of around filters that are executed before a Hypertext Transfer Protocol (HTTP) request is dispatched to the actual business logic. This allows the business logic to be protected by authentication and authorization checks.
Many web applications have users logging in and logging out of the application. Once a user logs in to the application using a set of valid credentials, the user remains authenticated until the user logs out of the application. A typical method of implementing logging in and logging out may be embodied in the following pseudo code:
If the user's supplied credentials are valid then
Log the user in, including associating the user with the session
End if
Dissociate the user with the session.
The act of logging in may not be limited to the user using the web application user interface to enter his/her name and password. For example, it may be possible for a client application to log in for the user by providing username-password credentials via HTTP basic authentication. The client application may also use OAuth (an open protocol to allow secure application programming interface authorization in a simple or standard method from desktop and web applications), Security Assertion Markup Language (SAML) or some other Single Sign On (SSO) technology to log in for the user.
An HTTP request to an application system may carry information for the purpose of authentication and authorization. As such a system evolves, there is often the requirement to add support for new modes of authentication and new authorization checks. As the system grows in complexity and in the number of authentication and authorization schemes, it becomes harder to implement new schemes that are correct, and work well along with other existing schemes, without introducing new vulnerabilities.
Also, credentials such as username-password can be carried via multiple transport mechanisms, for example, HTTP basic authentication, HTTP request body, some form of an encrypted token and the like. For a given kind of credential, there is typically only one mechanism to validate the credentials and authenticate the user. With existing technologies, the credential gathering and the authentication mechanism are typically coupled, thus requiring each credential gatherer to be able to validate the credentials itself. This may lead to potential vulnerabilities as new modules are added that claim to operate on the same kind of credentials, (e.g., username-password), but differ in how they validate those credentials.
Similar difficulties are also present in session management. Depending on the circumstances, different steps need to be executed when the user logs in or logs out. With existing technologies, these steps are implemented in an ad-hoc fashion with the consequence that multiple pieces of such logic may not interact well. This may also introduce security vulnerabilities if, for example, the user identity changes but the code is still running with the old user's privileges.
Various embodiments of systems and methods for integrated web application security framework are described herein. In one embodiment, the method includes receiving an HTTP request and performing a session validation. The method also includes establishing and verifying a user identity and authorizing the user identity and a user action. The method further includes performing login/logout processing and associating rights to a user or the session.
In another embodiment, the system includes a browser configured to send an HTTP request to a web server and a set of modules associated with the web server. The system further includes a processor configured to execute the set of modules. The set of modules includes a session validator module configured to determine whether an existing session is invalidated; a credential provider module configured to provide credentials of a given kind, the credentials extracted from the HTTP request; an authenticator module configured to verify credentials provided by the credential provider module and to produce an authenticated user identity for a user; a logout check provider module configured to determine whether the user should be logged out; an authorization token provider module configured to provide authorization tokens that provide for levels of authorization; and an authorizer module configured to determine whether the HTTP request is authorized, given the authenticated user identity and the authorization tokens.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for integrated web application security framework are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
For the set of modules 117, there may be one, more than one, or no components of a type. The number of authenticators 130 depends on the types of credentials as extracted by an installed credential provider 125. Typically, there is exactly one authenticator 130 per type of credential extracted by a credential provider 125. In one embodiment, when there are no components of a specified type, the associated steps are skipped in the logic. For example, when there are no credential providers 125, no authenticators 130 are executed. Also, when there are one or more credential providers 125 but none of them extracted any credentials, no authenticators 130 are executed.
Table 1 is a table representing the possible state transitions between logged in and logged out states, and the associated actions taken according to an embodiment of a method for integrated web application security framework.
The used states are ε for NOBODY or anonymous identity, a first identity A, and a second identity B.
If the session started with NOBODY or an anonymous user (ε) but the authentication process establishes a new user identity that is not NOBODY nor an anonymous identity (A or B), login processing logic is performed. If the session started with a user identity that is not NOBODY nor an anonymous identity (A or B), and the authentication process established NOBODY or an anonymous identity (ε) as the user identity, logout processing logic is performed. If the session started with a user identity that is not NOBODY nor an anonymous identity (A), and the authentication process established a different user identity that is also not NOBODY nor an anonymous identity (B), and the ALLOW_ATOMIC_LOGOUT_LOGIN configuration flag is specified, logout processing is first performed, followed by login processing.
If no multiple credentials resulting in conflicting user credentials are present, the process continues to decision block 460, to check if the existing logged-in user associated with the session differs from the authenticated user identity. If the existing logged-in user associated with the session differs from the authenticated user identity, the process continues to decision block 463, to check if the ALLOW_ATOMIC_LOGOUT_LOGIN configuration flag is not specified. If the configuration flag is not specified, the error is reported at block 465 and the process is halted at block 467. If the configuration flag is specified at block 463, then the process continues at decision block 470 in
If, at decision block 460, the existing logged-in user associated with the session does not differ from the authenticated user identity, the process continues at decision block 470. At decision block 470, a check is performed to determine whether there are any authentication results. If there is at least one authentication result at block 470, the user identity is set to a consensus value at block 475 and the process continues to decision block 480. The consensus value may be the authentication identity agreed to by all of the authentication results that come after the block 450 or a special value representing NOBODY, e.g., the value of nil in the Ruby programming language. If there are no authentication results at block 470, at block 477 the user identity is set to the value previously stored in the session (i.e., the existing logged-in user associated with the session as compared against at decision block 460), and the process continues at decision block 480. At decision block 480, a check is performed for determined logout request. If at least one logout request is determined, then at block 485, the user identity is set to NOBODY and the process continues at decision block 490. If no logout request is determined at block 480, the process continues at decision block 490. At decision block 490, a check is performed to determine if the authentication results in a NOBODY identity or user identity is not authenticated. If such condition is determined at block 490, then at block 495 an anonymous identity is obtained and set as the user identity. An anonymous identity is a proxy with the same effective rights as the NOBODY identity.
In one embodiment, the application security framework is installed globally at the root class of all controllers in the application. When the application follows Ruby on Rails convention, this root class would be the ApplicationController class. This in turn installs an around filter, which is capable of allowing or blocking the request from being processed and ensuring that unintentional changes to the session state are reverted after the request processing is finished. Once the framework is installed, callbacks can be registered for performing various actions. These callbacks can be registered at the root controller class level or at the individual subclass level. Callbacks, like filters, are passed on from parent class to child class. The kinds of callbacks that can be registered may be, for example, session validators, credential providers, authenticators, etc.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.