Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A method and system for mediating security tokens to authorization data
transactions in a data management system. The methods and systems
intercept a data request between two applications or services, and
validate and translate a security token sent with the data request from a
format compatible with the first application or service to a format
compatible with the second application or service.

Claims:

1. A method of processing a query, comprising: receiving a data request
from a first application that is directed to a second application;
receiving a first token in a first credential format from the first
application; validating the first token; issuing a second token in a
second credential format compatible with the second application by
translating the first token into a second credential format; and sending
the data request and the second token to the second application.

2. The method of claim 1, wherein the first and second credential formats
are different, and are individually selected from the group consisting of
Kerberos, Liberty, Security Assertion Markup Language (SAML), Web
Services Federation (WS-Federation), Web Services Security (WS-Security),
and Web Services Trust (WS-Trust).

3. The method of claim 1, wherein the first credential format and the
second credential format are different XML credential standards.

4. The method of claim 1, further comprising: mapping a user identity for
a user of the first application.

5. The method of claim 4, further comprising: retrieving attributes of
the user identity from an authentication server.

6. The method of claim 1, wherein said validation further comprises:
performing an authentication check that the first application is
authorized to access the second application against an authentication
server, wherein if the first application is not authorized, the second
token indicates such lack of authorization.

7. The method according to claim 1, wherein at least one of the steps is
implemented on a computer system.

8. A computer program product comprising a computer useable medium having
a computer readable program, wherein the computer readable program when
executed on a computer causes the computer to: receive a data request
from a first application that is directed to a second application;
receive a first token in a first credential format from the first
application; validate the first token; issue a second token in a second
credential format compatible with the second application by translating
the first token into a second credential format; and send the data
request and the second token to the second application.

9. The computer program product of claim 8, wherein the first and second
credential formats are different, and are individually selected from the
group consisting of Kerberos, Liberty, Security Assertion Markup Language
(SAML), Web Services Federation (WS-Federation), Web Services Security
(WS-Security), and Web Services Trust (WS-Trust).

10. The computer program product of claim 8, wherein the first credential
format and the second credential format are different XML credential
standards.

11. The computer program product of claim 8, wherein the computer
readable program when executed on a computer further causes the computer
to: map a user identity for a user of the first application.

12. The computer program product of claim 8, wherein the computer
readable program when executed on a computer further causes the computer
to: retrieve attributes of the user identity from an authentication
server.

13. The computer program product of claim 8, wherein the computer
readable program when executed on a computer further causes the computer
to: perform an authentication check that the first application is
authorized to access the second application against an authentication
server, wherein if the first application is not authorized, the second
token indicates such lack of authorization.

14. The computer program product of claim 8, wherein the computer program
product is stored on a computer useable optical storage medium.

15. The computer program product of claim 8, wherein the computer program
product is stored on a hard disk.

16. A system comprising: a memory having validation information stored
therein; and a processor configured with logic to: receive a data request
from a first application that is directed to a second application;
receive a first token in a first credential format from the first
application; validate the first token; issue a second token in a second
credential format compatible with the second application by translating
the first token into a second credential format; and send the data
request and the second token to the second application.

17. The system of claim 16, wherein the first and second credential
formats are different, and are individually selected from the group
consisting of Kerberos, Liberty, Security Assertion Markup Language
(SAML), Web Services Federation (WS-Federation), Web Services Security
(WS-Security), and Web Services Trust (WS-Trust).

18. The system of claim 16, wherein the first credential format and the
second credential format are different XML credential standards.

19. The system of claim 16, the processor being further configured with
the logic to: map a user identity for a user of the first application.

20. The system of claim 19, the processor being further configured with
the logic to: retrieve attributes of the user identity from an
authentication server.

21. The system of claim 16, the processor being further configured with
the logic to: perform an authentication check that the first application
is authorized to access the second application against an authentication
server, wherein if the first application is not authorized, the second
token indicates such lack of authorization.

Description:

BACKGROUND

[0001] 1. Technical Field

[0002] The present invention relates generally to a token mediation
service, and more particularly to systems and methods for using a token
mediation service and security tokens to authorize database transactions
in a data management system.

[0003] 2. Discussion of Related Art

[0004] Enterprises generally desire to provide authorized users with
secure access to protected resources in a user-friendly manner throughout
a variety of networks, including the Internet. Although providing secure
authentication mechanisms reduces the risks of unauthorized access to
protected resources, those authentication mechanisms may become barriers
to accessing protected resources.

[0005] Users generally desire the ability to change from interacting with
one application to another application without regard to authentication
barriers that protect each particular system supporting those
applications. A user might assume that once he or she has been
authenticated by some computer system, the authentication should be valid
throughout the user's working session, or at least for a particular
period of time, without regard to the various computer architecture
boundaries that are almost invisible to the user. Subjecting a user to
multiple authentication processes in a given time frame may significantly
affect the user's efficiency.

[0006] Moreover, maintaining different authorization and authentication
credentials, and requiring each application to obtain or validated
security credentials for each access by a user slows down network speed,
increases network traffic, and requires maintenance by the system
administrator, thus significantly affecting the network's efficiency.
Further, point-to-point authentication is inefficient and slows down
execution of a data request.

BRIEF SUMMARY

[0007] Accordingly, embodiments of the present invention include a method
of processing a query, comprising receiving a data request from a first
application that is directed to a second application, receiving a first
token in a first credential format from the first application, validating
the first token, issuing a second token in a second credential format
compatible with the second application by translating the first token
into a second credential format, and sending the data request and the
second token to the second application.

[0008] Other embodiments of the present invention include a computer
program product comprising a computer useable medium having a computer
readable program, where the computer readable program when executed on a
computer causes the computer to receive a data request from a first
application that is directed to a second application, receive a first
token in a first credential format from the first application, validate
the first token, issue a second token in a second credential format
compatible with the second application by translating the first token
into a second credential format, and send the data request and the second
token to the second application.

[0009] Still other embodiments of the present invention include a system
comprising a memory having validation information stored therein, and a
processor configured with logic to receive a data request from a first
application that is directed to a second application, receive a first
token in a first credential format from the first application, validate
the first token, issue a second token in a second credential format
compatible with the second application by translating the first token
into a second credential format, and send the data request and the second
token to the second application.

[0010] The above and still further features and advantages of embodiments
of the present invention will become apparent upon consideration of the
following detailed description thereof, particularly when taken in
conjunction with the accompanying drawings wherein like reference
numerals in the various figures are utilized to designate like
components.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0011]FIG. 1 is a block diagram illustrating an exemplary token mediation
service used in a data management system according to an embodiment of
the present invention.

[0012]FIG. 2 is a block diagram illustrating the flow of data requests
and tokens in a data management system according to an embodiment of the
present invention.

[0013]FIG. 3 is a flowchart depicting a process for requesting,
validating and issuing security tokens in a token mediation service in a
data management system according to an embodiment of the present
invention.

DETAILED DESCRIPTION

[0014] Referring now to the Figures, an exemplary system according to an
embodiment of the present invention is illustrated in FIG. 1. The system
shown in FIG. 1 is particularly suited to the mediation of security
tokens in a data management system, for example a federated data
management system. The system includes token mediator module 20, memory
30, database management system (DBMS) 40, application server 50, and
security token service 60, all of which are connected over networks 71,
72, 73, 74 to each other and via Enterprise Service Bus (ESB) layer 10 to
a user portal 5. The system 100 may include additional servers, clients,
and other devices not shown, and individual components of the system may
occur either singly or in multiples, for example, there may be more than
one DBMS in the system.

[0016] The token mediator module 20 may be implemented in the form of a
processing system, or may be in the form of software. A processing system
may be implemented by any conventional or other computer or processing
systems preferably equipped with a display or monitor, a base (e.g.,
including the processor, memories and/or internal or external
communications devices (e.g., modem, network cards, etc.) and optional
input devices (e.g., a keyboard, mouse or other input device)). If
embodied in software, the token mediator module 20 may be available on a
recordable medium (e.g., magnetic, optical, floppy, DVD, CD, etc.) or in
the form of a carrier wave or signal for downloading from a source via a
communication medium (e.g., bulletin board, network, LAN, WAN, Intranet,
Internet, etc.). For example, the token mediator module 20 can be
implemented as software, for example one or more daemons, software
modules, or APIs.

[0017] Memory 30 may be implemented by any conventional or other memory or
storage device (e.g., RAM, cache, flash, etc.), and may include any
suitable storage capacity.

[0020] Security token service 60 provides token issuance and validation
services required by the token mediator module 20, either alone or in
combination with access manager 62. The security token service 60 invokes
the access manager 62 as necessary, for example to consult an access
control list to determine if a user is authorized access to a particular
application or database, for example publication access or subscription
access. In certain embodiments, for example embodiments used in a
federated computing environment, the security token service 60 may be
implemented using IBM Tivoli Federated Identity Manager, and the access
manager 62 may be implemented using IBM Tivoli Access Manager.

[0021] The networks 71, 72, 73, 74 may be implemented by any quantity of
any suitable communications media (e.g., WAN, LAN, Internet, Intranet,
wired, wireless, etc.). The computer systems of the present invention
embodiments may include any conventional or other communications devices
to communicate over the networks via any conventional or other protocols,
and may utilize any type of connection (e.g., wired, wireless, etc.) for
access to the network. It is understood that any of the user portal 5,
token mediator module 20, memory 30, DBMS 40, and application server 50
may be local to one or more components of system 100, or may be remote
from and in communication with one or more other components of system 100
via one or more networks 71, 72, 73, 74.

[0022] For purposes of illustration, FIG. 1 depicts the token mediator
module 20, database server 42 and application server 50 as entities
separate and distinct from each other. It is understood that the module
20 and servers 42 and 50 may also be implemented, for example, on a
single server (e.g., as logically distinct modules), distributed on
portions of several servers, or as part of a single server node or server
farm in communication with the system 100 through, for example, a web
server.

[0023] In operation, the token mediator module 20 provides a way to
implement security policies and access control in a single module as
opposed to being spread across the entire data management system. When a
user requests access to a database or application, the token mediator
module 20 intercepts the request and the authentication criteria supplied
by the user, and adjudicates the access request itself (either alone or
in combination with security token service 60 and/or access manager 62)
based on access rules or policies stored in memory 30.

[0024] Referring now to FIG. 2, a simplified version of system 100 is
depicted, showing only the elements involved in a particular data
transaction. In this embodiment, a J2EE application 54 makes a data
request 210 to a DB2 database 44 requesting a response, and with the
request includes a first token (Token 1) in a first credential format,
such as LTPA, SAML 1.0, or the like. This data request 210 is intercepted
by the token mediator module 20, which then adjudicates the data request
by validating the first token, translating the first token (if valid)
into a second credential format, such as SAML 2.0, a WS-Trust format, or
the like, and issuing a second token (Token 2) in the second credential
format. The token mediator module 20 then sends a data request 212 to the
DB2 database 44, and with the request includes the second token (Token
2). The DB2 database 44 receives the data request 212 and the second
token, processes the request according to the received authorization (in
the form of the token), and sends a response 220 back to the requesting
application 54.

[0025] As used herein, the terms "request" and "response" should be
understood to comprise data formatting that is appropriate for the
transfer of information that is involved in a particular operation, such
as messages, communication protocol information, or other associated
information. The first and second credential formats can be any suitable
credential format, for example, challenge/response information, Kerberos,
Liberty, PKI certificates, Security Assertion Markup Language (SAML)
versions such as 1.0 and 2.0, user name and password combinations, Web
Services Federation (WS-Federation), WS-Security, WS-Trust, a XML
credential standard, etc. The term "token" is used herein to refer to a
particular set of credentials, however it is understood that this term
refers to any suitable set of credentials, for example a WS-Federation
token, a SAML assertion, a PKI certificate, etc.

[0026] Although described in terms of an application passing a request to
a database, it is understood that the token mediator module 20 provides
full bi-directional service, and that a database may pass a request to an
application or service, or vice-versa, and that a request need not
originate from a J2EE application, .NET application, Java service, or any
other specific module in the system.

[0027] Optionally, the token mediator module 20 may perform an
authorization against the security token service 60, for example by
sending an authorization request 230 to the security token service 60,
and receiving in response an authorization response 232. The security
token service 60 may also perform an authorization against the access
manager 62, for example by sending a request 240 to consult an access
control list to the access manager 62, and receiving a response 242 after
the access manager 62 has consulted the appropriate access control list.

[0028] Generally, the token mediator module 20 that has been previously
described performs the steps of FIG. 3. Referring now to FIG. 3, the
reference numeral 300 generally designates a flow chart depicting a
process for mediating security tokens in a data management system. In
step 310, the token mediator module intercepts a data request from a
first application to a second application, and in step 320, the module
receives a first token in a first credential format (e.g., an LTPA token)
from the first application. In step 330, the module validates the first
token by consulting validation information, for example validation
information stored in a validation or authorization database or server,
and in step 340 translates the validated first token into a second token
in a second credential format (e.g., a SAML 2.0 assertion), and issues
the second token. In step 350, the module releases the data request to
the second application (for example by releasing the intercepted data
request and replacing the first token therein with the second token,
sending a new data request incorporating relevant portions of the
intercepted data request along with the second token, etc.), and in step
360 the module sends the second token to the second application.

[0029] Optionally, the module may perform additional steps as part of the
validation and translation process, for example in step 331 the module
maps the user identity, and in step 332 the module retrieves additional
attributes for the identity. The module may also perform optional step
333 in which it sends an authorization request, and step 334 in which it
receives an authorization response, if further authorization is desired,
for example against an authorization server and/or access manager, such
as IBM Tivoli Federated Identity Manager, IBM Tivoli Access Manager, or
the like. Additionally, the module may perform optional step 335 in which
it checks (or requests an authorization server to check) an access
control list to consult the access control settings or permissions for
the requested application or service, and optional step 336 in which it
receives access parameters for the requested application or service.

[0030] The first token may be pre-existing, or may be obtained from an
authentication engine appropriate for the first application's security
domain, e.g., a Java Authentication and Authorization Service
authentication engine or Tivoli Access Manager Authorization Server for a
Java security domain.

[0031] Advantages of the methods and systems using the token mediator
module embodiments described herein include the ability to support a
variety of credentials and asserts (whether standard or custom), the
elimination of inefficient point-to-point communication between the token
provider and token consumers, removal of multiple hops required to obtain
and pass tokens, and true abstract mediation of tokens at runtime, all in
a secure and scalable manner. The token mediator module may sit on top of
pluggable authentication modules to provide true hub-and-spoke round-trip
authentication, mapping and routing services. Further, as evident from
the preceding discussion, the token mediator module does not require any
support from the system passing the request (e.g., the application
server) or the system that consumes the request (e.g., the database
system).

[0032] As will be appreciated by one skilled in the art, aspects of the
present invention may be embodied as a system, method or computer program
product. Accordingly, aspects of the present invention may take the form
of an entirely hardware embodiment, an entirely software embodiment
(including firmware, resident software, micro-code, etc.) or an
embodiment combining software and hardware aspects that may all generally
be referred to herein as a "circuit," "module" or "system." Furthermore,
aspects of the present invention may take the form of a computer program
product embodied in one or more computer readable medium(s) having
computer readable program code embodied thereon.

[0033] Any combination of one or more computer readable medium(s) may be
utilized. The computer readable medium may be a computer readable signal
medium or a computer readable storage medium. A computer readable medium
may be, for example, but is not limited to, an electronic, magnetic,
optical, electromagnetic, infrared, or semiconductor system, apparatus,
or device, or any suitable combination of the foregoing. More specific
examples (a non-exhaustive list) of the computer readable storage medium
would include the following: an electrical connection having one or more
wires, a portable computer diskette, a hard disk, a random access memory
(RAM), a read-only memory (ROM), an erasable programmable read-only
memory (EPROM or Flash memory), an optical fiber, a portable compact disc
read-only memory (CD-ROM), an optical storage device, a magnetic storage
device, or any suitable combination of the foregoing. In the context of
this document, a computer readable storage medium may be any tangible
medium that can contain, or store a program for use by or in connection
with an instruction execution system, apparatus, or device.

[0034] A computer readable signal medium may include a propagated data
signal with computer readable program code embodied therein, for example,
in baseband or as part of a carrier wave. Such a propagated signal may
take any of a variety of forms, including, but not limited to,
electro-magnetic, optical, or any suitable combination thereof. A
computer readable signal medium may be any computer readable medium that
is not a computer readable storage medium and that can communicate,
propagate, or transport a program for use by or in connection with an
instruction execution system, apparatus, or device. Program code embodied
on a computer readable medium may be transmitted using any appropriate
medium, including but not limited to wireless, wireline, optical fiber
cable, RF, etc., or any suitable combination of the foregoing.

[0035] Computer program code for carrying out operations for aspects of
the present invention may be written in any combination of one or more
programming languages, including an object oriented programming language
such as Java, Smalltalk, C++ or the like and conventional procedural
programming languages, such as the "C" programming language or similar
programming languages. The program code may execute entirely on the
user's computer, partly on the user's computer, as a stand-alone software
package, partly on the user's computer and partly on a remote computer or
entirely on the remote computer or server. In the latter scenario, the
remote computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area network
(WAN), or the connection may be made to an external computer (for
example, through the Internet using an Internet Service Provider).

[0036] It is to be understood that the software for the computer systems
of the present invention embodiments may be implemented in any desired
computer language and could be developed by one of ordinary skill in the
computer arts based on the functional descriptions contained in the
specification and flow charts illustrated in the drawings. By way of
example only, the software may be implemented in the C#, C++, Python,
Java, or PHP programming languages. Further, any references herein of
software performing various functions generally refer to computer systems
or processors performing those functions under software control.

[0037] The computer systems of the present invention embodiments may
alternatively be implemented by any type of hardware and/or other
processing circuitry. The various functions of the computer systems may
be distributed in any manner among any quantity of software modules or
units, processing or computer systems and/or circuitry, where the
computer or processing systems may be disposed locally or remotely of
each other and communicate via any suitable communications medium (e.g.,
LAN, WAN, Intranet, Internet, hardwire, modem connection, wireless,
etc.).

[0038] Aspects of the present invention are described with reference to
flowchart illustrations and/or block diagrams of methods, apparatus
(systems) and computer program products according to embodiments of the
invention. It will be understood that each block of the flowchart
illustrations and/or block diagrams, and combinations of blocks in the
flowchart illustrations and/or block diagrams, can be implemented by
computer program instructions. These computer program instructions may be
provided to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to produce a
machine, such that the instructions, which execute via the processor of
the computer or other programmable data processing apparatus, create
means for implementing the functions/acts specified in the flowchart
and/or block diagram block or blocks.

[0039] These computer program instructions may also be stored in a
computer readable medium that can direct a computer, other programmable
data processing apparatus, or other devices to function in a particular
manner, such that the instructions stored in the computer readable medium
produce an article of manufacture including instructions which implement
the function/act specified in the flowchart and/or block diagram block or
blocks. The computer program instructions may also be loaded onto a
computer, other programmable data processing apparatus, or other devices
to cause a series of operation steps to be performed on the computer,
other programmable apparatus or other devices to produce a computer
implemented process such that the instructions which execute on the
computer or other programmable apparatus provide processes for
implementing the functions/acts specified in the flowchart and/or block
diagram block or blocks.

[0040] A processing system suitable for storing and/or executing program
code may be implemented by any conventional or other computer or
processing systems preferably equipped with a display or monitor, a base
(e.g., including the processor, memories and/or internal or external
communications devices (e.g., modem, network cards, etc.) and optional
input devices (e.g., a keyboard, mouse or other input device)). The
system can include at least one processor coupled directly or indirectly
to memory elements through a system bus. The memory elements can include
local memory employed during actual execution of the program code, bulk
storage, and cache memories which provide temporary storage of at least
some program code in order to reduce the number of times code must be
retrieved from bulk storage during execution. Input/output or I/O devices
(including but not limited to keyboards, displays, pointing devices,
etc.) can be coupled to the system either directly or through intervening
I/O controllers. Network adapters may also be coupled to the system to
enable the system to become coupled to other processing systems or remote
printers or storage devices through intervening private or public
networks. Modems, cable modem and Ethernet cards are just a few of the
currently available types of network adapters.

[0041] The flowchart and block diagrams in the Figures illustrate the
architecture, functionality, and operation of possible implementations of
systems, method and computer program products according to various
embodiments of the present invention. In this regard, each block in the
flowchart or block diagrams may represent a module, segment, or portion
of code, which comprises one or more executable instructions for
implementing the specified logical function(s). It should also be noted
that, in some alternative implementations, the functions noted in the
block may occur out of the order noted in the Figures. For example, two
blocks shown in succession may, in fact, be executed substantially
concurrently, or the blocks may sometime be executed in the reverse
order, depending on the functionality involved. It will also be noted
that each block of the block diagrams and/or flowchart illustration, and
combinations of blocks in the block diagrams and/or flowchart
illustration, can be implemented by special purpose hardware-based
systems that perform the specified functions or acts, or combinations of
special purpose hardware and computer instructions.

[0042] The terminology used herein is for the purpose of describing
particular embodiments only and is not intended to be limiting of the
invention. As used herein, the singular forms "a", "an" and "the" are
intended to include the plural forms as well, unless the context clearly
indicates otherwise. It will be further understood that the terms
"comprises" and/or "comprising," when used in this specification, specify
the presence of stated features, integers, steps, operations, elements,
and/or components, but do not preclude the presence or addition of one or
more features, integers, steps, operations, elements, components, and/or
groups thereof.

[0043] The corresponding structures, materials, acts, and equivalents of
all means or step plus function elements in the claims below are intended
to include any structure, material, or act for performing the function in
combination with other claimed elements as specifically claimed. The
description of the present invention has been presented for purposes of
illustration and description, but is not intended to be exhaustive or
limited to the invention in the form disclosed. Many modifications and
variations will be apparent to those of ordinary skill in the art without
departing from the scope and spirit of the invention. The embodiment was
chosen and described in order to best explain the principles of the
invention and the practical application, and to enable others of ordinary
skill in the art to understand the invention for various embodiments with
various modifications as are suited to the particular use contemplated.