Security architecture for authentication and audit

A mechanism for consolidating communications between a computer tenant and a web services layer is provided. The mechanism may include a web services layer. The web services layer may be configured to receive communications, via an authentication validation module, from an authentication service. The authentication service may be in communication with the computer tenant and/or the web services layer. The web services layer may be configured to receive authorization data, via an authorization module, from an authorization data store. The web services layer may also receive and transmit logged calls from a log database. The logged calls may store calls from the computer tenant to the web services layer and calls from the web services layer to the authentication server. The computer tenant may initiate communication with the web services layer. Included in the communications may be a token.

FIELD OF TECHNOLOGY

Aspects of the invention relate to providing mechanism/apparatus to implement security in web services. In particular, the disclosure relates to implementing authentication, authorization and audit in web services by centralizing the architecture for security within the web services layer.

BACKGROUND OF THE DISCLOSURE

Large enterprises use a plurality of systems where the systems utilize various web services to create new applications and/or retrieve information from different systems of record or legacy applications. Application security is a concern as different applications use different security measures during integration.

Additionally, authentication, authorization and audit (“AAA”) when building applications require dedicated AAA server or third party tools to be integrated with the web services layer.

This is not desirable because it involves additional layers of integration and increases the dependencies of other systems. Security costs and risk of information leakage are increased as well.

Therefore, it would be desirable to have a centralized architecture within the web services layer that will handle the combination of the AAA for each request.

SUMMARY OF THE INVENTION

A method for centralizing within a web services layer authentication, authorization and audit of user activity is provided. A user or a web application consumes the functionality provided by the web services.

A web services layer may be understood, for the purposes of the application, to be a software system for transmitting data over the internet/intranet and allowing programmatic access to that data using standard internet protocols. The web services layer may be added to a graphical user interface (“GUI”) and may offer specific functionalities to users. Access to the web services layer may be enabled on the GUI using a web interface.

The method may involve receiving a user ID, a password, and/or ID token at the web services layer. The ID token may be registered with a Ping security token service (“STS”). The Ping STS may be in communication with the web services layer.

The web services layer may communicate the user ID, password and/or ID token to the Ping STS. In response to the Ping STS's receipt of the communication, the method may further involve using the Ping STS to generate a one-time security assertion markup language (“SAML”) token. The SAML token may contain client identification and an associated privilege level of user access to operations at the web services layer. The privilege level may be based on information stored at the Ping STS related to identification. The SAML token may expire after a pre-determined time thereby preventing other-user access to the service via the same SAML token. The SAML token may also enable secure access to the web interface.

The method may further involve transmitting the SAML token to the web services layer. The web services layer may verify the SAML token and authenticate the user.

The method may further involve authorizing the requested user operation based on the privilege level incorporated in the SAML token. The authorizing may further include transmitting information about user identification (“userid”) and access privileges from the SAML token to a central repository system (“CRS”) in a simple object access protocol (“SOAP”) message, and based on the privilege level, the CRS may confirm permissibility of the requested operation to the web services layer.

In certain embodiments, the web services layer may either authorize or deny the requested user operation.

The method may further involve logging a user's actions at the web services layer. The logging may further involve integrating a remote or third-party logging system with the web services layer. The logging system may enable searching and tracking of the user's actions.

DETAILED DESCRIPTION OF THE DISCLOSURE

Some embodiments may involve a method for centralizing authentication, authorization and audit of user activity in a web services layer. The web services layer may be on a web server.

Web services may incorporate a second web services functionalities. A third party may provide the functionalities of the web services layer and the additional web services. The incorporation of the original web services and additional web services layer may now create a third bundled web services layer. The importance of centralizing the AAA at the web services layer is integral where several web services are incorporated together with the original web services layer.

The method may involve receiving a user ID, a password, and/or ID token, and a service request at the web services layer. The ID token may be registered with a Ping security token service (“STS”).

In some embodiments, the Ping STS may be local to the web services layer on the web server and improve the speed of transmitting data.

In some embodiments, the Ping STS may be remote to the web services layer on the web server.

Through registering directly with Ping STS, the web services layer does not need to maintain user profiles for each consumer. The Ping STS may be in communication with the web services layer.

The web services layer may communicate the user ID, password, ID token, and/or service request to the Ping STS. In response to the Ping STS's receipt of the communication, the method may further involve using the Ping STS to generate a one-time security assertion markup language (“SAML”) token. The SAML token may contain client identification and attributes for authorization of the service request and operation. On successful authentication of the user, the authorization may include either authorizing or denying user access to the requested service operation.

The SAML token may be transmitted to the web services layer. Upon retrieval of the SAML token with the previously-determined authorization incorporated within, the web services layer may either execute or deny access to the requested user operation.

The method may further involve logging a user's actions at the web services layer. The logging may further involve integrating a remote or third-party logging system with the web services layer. The logging system may enable searching and tracking of the user's actions.

Some embodiments involve a centralized architecture for authentication, authorization and audit of user activities within a web services layer. The centralized architecture for authentication, authorization and audit (“AAA”) may be within the web services layer.

The web services layer may be configured to receive a user ID, a password and/or identification token (“ID”). The ID token may be located in a header of a communication from a user.

The mechanism may also include a Ping STS. The Ping STS generates a security assertion markup language (“SAML”) token. The SAML token may be in certain embodiments, a one-time use(“OTU”) SAML token.

In certain embodiments the web services layer may receive the user ID, the password and/or the ID token via a header of a simple object access protocol (“SOAP”) message. The web services layer may transmit the ID token to the Ping STS. The Ping STS may authenticate the SAML token corresponding to the user ID, password and/or security level associated with the user. The SAML token may also be transmitted back.

The mechanism may further include a central repository system (“CRS”). The CRS may maintain a directory of resources and levels of security required for accessing each resource. The web services layer may be configured to transmit the resource requested and information from the SAML token to the CRS. The CRS may confirm, based on security level as per the information from the SAML token, whether the resource request may be executed or denied.

In response to the previously-determined confirmation, the web services layer may be configured to either authorize or deny the requested resource. The authorization occurring at the web services layer may eliminate additional layers and only grant access to permitted operations.

The method may further involve logging a user's actions at the web services layer. The logging may further involve integrating a remote or third-party logging system with the web services layer. The logging system may enable searching and tracking of the user's actions.

Some embodiments may include preventing authentication bypass by a user for accessing the web services. The method may comprise integrating authentication of the user at the web services layer. The integration at the web services layer may in certain circumstances eliminate an additional layer of integration. The elimination of integration may enable creating one direct endpoint. The elimination of integration may further result in forcing an authorization check and thereby granting access to only permitted operations.

The drawings show illustrative features of mechanism and methods in accordance with the principles of the invention. The features are illustrated in the context of selected embodiments. It will be understood that features shown in connection with one of the embodiments may be practiced in accordance with the principles of the invention along with features shown in connection with another of the embodiments.

Mechanisms and methods described herein are illustrative. Mechanisms and methods of the invention may involve some or all of the features of the illustrative mechanism and/or some or all of the steps of the illustrative methods. The steps of the methods may be performed in an order other than the order shown or described herein. Some embodiments may omit steps shown or described in connection with the illustrative methods. Some embodiments may include steps that are not shown or described in connection with the illustrative methods, but rather shown or described in a different portion of the specification.

FIG. 1shows a conventional mechanism with additional layers of integration. Step102shows a user attempting to request a service via an enterprise integration gateway (“EIG”) layer. The EIG layer104may be used for authorizing the user's service request110and logging the received calls shown at112with a logging service shown at114.

Authorization of a user, as shown at110may require the user's identification and service request to be transmitted to the web services layer106. The web services layer106may then transmit the user's identification and service request to the CRS/data store as shown at108for determination of authorization of a service request. The response may then be returned to the EIG layer via the web services layer and may either authorize or deny the requested service.

Logging114may only track those calls received at the EIG layer.

A user may be able to directly connect to the services without going through the EIG layer104for authorization110via a lower level and by using direct endpoints. This may increase the risk for access to all service operations without authorization of the service request. The EIG layer104may also increase the response time for processing a service request.

Authentication for the user, shown at116, may be done at the web services layer106. Web services layer106may need to maintain an active directory of user profiles shown at118to be able to authenticate a user. Maintenance of an active directory at the web services layer106may also increase the response time for processing service request Ping STS. SPLUNK114may only track and log calls received at the EIG layer104. Logging shown at120, may require logging to an enterprise integration hub. Logging120may only track and log calls received at the web services layer106.

Web services teams may not have the ability to view, filter, or search the logs shown at114because this logging was done prior to calls received at the web services layer.

FIG. 2shows an illustrative flow diagram in accordance with the principles of the invention. Step202shows a user interacting with the web services layer to authorize a service request. A user shown at202may be registered with a Ping STS system shown at206. The Ping STS206may, in response to receiving user login information, verify the user identification and generate a SAML token containing the user's identification information. The SAML token may be transmitted to the web services layer.

At step204, the web services layer may receive the SAML token and may authenticate the user as shown at212.

The web services layer204may also authorize the user request shown at210. The authorization may include using a central repository system (“CRS”)208. Web services layer204may transmit the SAML token and service requested to the CRS208. CRS208may determine permissibility for the service requested and return authorization for the service to the web services layer204. Web services layer204may accept the authorization and may perform the service requested shown at210. Alternatively, the CRS208may respond with a denial of the request.

Logging to enterprise integration hub, as shown at214may be logged with a logging system216. All services and calls that may take place at the web services layer204and/or during transmittal of the identification information, may be included in the logging system216. A web services team may have the ability to view, filter, search and track user actions shown at logging system216.

FIG. 2shows an illustrative flow diagram in accordance with the principles of the invention. Elements302,304,306,308,310,312,314and316correspond to elements202,204,206,208,210,212,214and216inFIG. 2.

In addition to what is shown inFIG. 2,FIG. 3shows an additional step. User identification information may be transmitted to the web services layer via a header in a SOAP message shown at step318.

At layer304, the web services layer may receive the SAML token and may authenticate the user shown at312.

The web services layer304may also authorize the user request shown at310. The authorization may include using a central repository system (“CRS”)308. Web services layer304may transmit a SOAP message320to the CRS308. SOAP message320may include the SAML token and service requested. CRS308may determine permissibility for the service requested and return authorization for the service via SOAP message320. Web services layer304may accept the authorization and may perform the service requested shown at310. Alternatively, the CRS308may respond with a denial of the request.

FIG. 4shows an illustrative mechanism in accordance with the principles of the invention.

Step402shows a web services AAA architecture. A web services requestor404may be a customer/user as shown at406. A web services requestor404may be a personal digital assistant (“PDA”) as shown at408. A web services requestor404may be an application as shown at410.

An XML security gate way412may be a security protection between the web services requestor404and the web services layer414.

A web services requestor404may need to be authenticated, authorized and audited. Authentication of a user, as shown at step416, may take place at the web services layer. Authentication416may use Ping STS, as shown at step422, to verify the identification of the web services requestor404.

In certain embodiments, the Ping STS422may be local to the web services layer414. In certain other embodiments, the Ping STS422may be remote to the web services layer414.

When the web services layer414authenticates a user, the service requested may need to be authorized as shown at step418.

Authorization418of a service requested may take place at the web services layer414. Authorization418may use an authorization server424for determining permissibility of the web services requestor404for a service requested.

In certain embodiments, the authorization server424may be local to the web services layer. In certain other embodiments, the authorization server424may be remote to the web services layer414.

All calls that take place at the web services requestor404and/or at the web services layer414may be audited and logged in SPLUNK or any other logging system, as shown at step420, at the web services layer414.

In certain embodiments, SPLUNK, or other logging system as shown at426, may be local to the web services layer414. In certain other embodiments, SPLUNK, or other logging system as shown at426, may be remote to the web services layer414.

Thus, systems and methods for centralizing the architecture for handling the AAA within the web services layer have been provided. Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation.