U.S. patent application number 13/034323 was filed with the patent office on 2011-09-01 for processor implemented systems and methods for using identity maps and authentication to provide restricted access to backend server processor or data.
Invention is credited to Robert Brian Hess, David Kerr Jeffreys.
Application Number | 20110214165 13/034323 |
Document ID | / |
Family ID | 44505851 |
Filed Date | 2011-09-01 |
United States Patent
Application |
20110214165 |
Kind Code |
A1 |
Jeffreys; David Kerr ; et
al. |
September 1, 2011 |
Processor Implemented Systems And Methods For Using Identity Maps
And Authentication To Provide Restricted Access To Backend Server
Processor or Data
Abstract
Systems and methods are provided for providing an application
access to an external data source or an external server process via
a connection server using an authentication server that has access
to an identity map. A credential request is received at the
authentication server from the connection server. The credential
request includes an identification of the external data source or
external server process to be accessed and an account identifier
associated with the application or a user of the application. The
identity map is searched for a set of credentials associated with
both the account identifier and the external data source or
external server process. The set of credentials are transmitted
from the authentication server to the connection server, for the
connection server to establish a connection to the external data
source or external server process, where the connection is
established without transmitting the set of credentials to the
application.
Inventors: |
Jeffreys; David Kerr;
(Raleigh, NC) ; Hess; Robert Brian; (Raleigh,
NC) |
Family ID: |
44505851 |
Appl. No.: |
13/034323 |
Filed: |
February 24, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61308635 |
Feb 26, 2010 |
|
|
|
Current U.S.
Class: |
726/5 |
Current CPC
Class: |
G06F 16/2471
20190101 |
Class at
Publication: |
726/5 |
International
Class: |
H04L 9/32 20060101
H04L009/32 |
Claims
1. A computer-implemented method of providing an application access
to an external data source or an external server process via a
connection server using an authentication server that has access to
an identity map, said method comprising: receiving a credential
request at the authentication server from the connection server,
wherein the credential request includes an identification of the
external data source or external server process to be accessed and
an account identifier associated with the application or a user of
the application; searching the identity map for a set of
credentials associated with both the account identifier and the
external data source or external server process; and transmitting
the set of credentials from the authentication server to the
connection server, for the connection server to establish a
connection to the external data source or external server process,
wherein the connection is for providing the application access to
the external data source or external server process, wherein the
connection is established without transmitting the set of
credentials to the application.
2. The method of claim 1, wherein the account identifier further
provides a group with which the application or the user of the
application is associated; wherein searching further includes
searching the identity map for a set of credentials associated with
both the group with which the application or the user of the
application is associated and the external data source or external
server process.
3. The method of claim 1, wherein the identity map is modified
based on authentication information received from an authentication
server administrator; wherein the authentication information
associates account identifiers and external data sources or
external service processes with credentials.
4. The method of claim 1, wherein not transmitting the set of
credentials to the application prohibits the application or a user
of the application from accessing the external data source or
external process without using the connection server.
5. The method of claim 1, wherein a user enters a username and
password combination to the application; wherein the connection
server verifies the username and password combination; wherein the
connection server generates an account identifier from the
application based on the verified username and password
combination; wherein the connection server transmits the account
identifier to the authentication server.
6. The method of claim 1, wherein the application is provided one
of a plurality of levels of access to the external data source or
external server process based on the set of credentials provided to
the connection server based on the searching the identity map.
7. The method of claim 1, wherein searching the identity map
includes determining a group with which the account identifier is
associated; and searching the identity map for a set of credentials
associated with both the group with which the account identifier is
associated and the external data source or external server
process.
8. A computer-implemented system for providing an application
access to an external data source or an external server process via
a connection server using an authentication server that has access
to an identity map, said system comprising: one or more data
processors; a computer-readable memory encoded with instructions
for commanding the one or more data processors to execute a method
comprising: receiving a credential request at the authentication
server from the connection server, wherein the credential request
includes an identification of the external data source or external
server process to be accessed and an account identifier associated
with the application or a user of the application; searching the
identity map for a set of credentials associated with both the
account identifier and the external data source or external server
process; and transmitting the set of credentials from the
authentication server to the connection server, for the connection
server to establish a connection to the external data source or
external server process, wherein the connection is for providing
the application access to the external data source or external
server process, wherein the connection is established without
transmitting the set of credentials to the application.
9. The system of claim 8, wherein the account identifier further
provides a group with which the application or the user of the
application is associated; wherein searching further includes
searching the identity map for a set of credentials associated with
both the group with which the application or the user of the
application is associated and the external data source or external
server process.
10. The system of claim 8, wherein the identity map is modified
based on authentication information received from an authentication
server administrator; wherein the authentication information
associates account identifiers and external data sources or
external service processes with credentials.
11. The system of claim 8, wherein not transmitting the set of
credentials to the application prohibits the application or a user
of the application from accessing the external data source or
external process without using the connection server.
12. The system of claim 8, wherein a user enters a username and
password combination to the application; wherein the application
verifies the username and password combination; wherein the
connection server receives an account identifier from the
application based on the verified username and password
combination; wherein the connection server transmits the account
identifier to the authentication server.
13. The system of claim 8 wherein the application is provided one
of a plurality of levels of access to the external data source or
external server process based on the set of credentials provided to
the connection server based on the searching the identity map.
14. The system of claim 8, wherein searching the identity map
includes determining a group with which the account identifier is
associated; and searching the identity map for a set of credentials
associated with both the group with which the account identifier is
associated and the external data source or external server
process.
15. A computer-readable medium encoded with instructions for
commanding one or more data processors to execute a method for
providing an application access to an external data source or an
external server process via a connection server using an
authentication server that has access to an identity map, said
method comprising: receiving a credential request at the
authentication server from the connection server, wherein the
credential request includes an identification of the external data
source or external server process to be accessed and an account
identifier associated with the application or a user of the
application; searching the identity map for a set of credentials
associated with both the account identifier and the external data
source or external server process; and transmitting the set of
credentials from the authentication server to the connection
server, for the connection server to establish a connection to the
external data source or external server process, wherein the
connection is for providing the application access to the external
data source or external server process, wherein the connection is
established without transmitting the set of credentials to the
application.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority to U.S. Provisional Patent
Application No. 61/308,635, filed Feb. 26, 2010, entitled
"Processor Implemented Systems and Methods for Using the Catalog
Part of a SQL Identifier to Expose/Access Heterogeneous Data." The
entirety of which is herein incorporated by reference.
FIELD
[0002] The technology described herein relates generally to
database access and more particularly to the use of identity maps
in conjunction with an authentication server to provide restricted
access to server data.
BACKGROUND
[0003] Applications can require access to data stored in secured
database servers (e.g., DBMS servers). Such access may be used to
produce reports or execute other tasks. Authorization enforcement
strategies may be employed to properly secure the data in the
database server on a per user basis to grant different privileges
to different users.
SUMMARY
[0004] Systems and methods are provided for providing an
application access to an external data source or an external server
process via a connection server using an authentication server that
has access to an identity map. A credential request may be received
at the authentication server from the connection server, where the
credential request includes an identification of the external data
source or external server process to be accessed and an account
identifier associated with the application or a user of the
application. The identity map may be searched for a set of
credentials associated with both the account identifier and the
external data source or external server process. The set of
credentials may be transmitted from the authentication server to
the connection server, for the connection server to establish a
connection to the external data source or external server process,
where the connection is for providing the application access to the
external data source or external server process and where the
connection is established without transmitting the set of
credentials to the application.
[0005] As another example, a system for providing an application
access to an external data source or an external server process via
a connection server using an authentication server that has access
to an identity map may include one or more data processors and a
computer readable memory encoded with instructions for commanding
the one or more data processors to execute a method. In the method,
credential request may be received at the authentication server
from the connection server, where the credential request includes
an identification of the external data source or external server
process to be accessed and an account identifier associated with
the application or a user of the application. The identity map may
be searched for a set of credentials associated with both the
account identifier and the external data source or external server
process. The set of credentials may be transmitted from the
authentication server to the connection server, for the connection
server to establish a connection to the external data source or
external server process, where the connection is for providing the
application access to the external data source or external server
process and where the connection is established without
transmitting the set of credentials to the application.
[0006] As a further example, a computer-readable memory may be
encoded with instructions for commanding one or more data
processors to execute a method for providing an application access
to an external data source or an external server process via a
connection server using an authentication server that has access to
an identity. In the method, credential request may be received at
the authentication server from the connection server, where the
credential request includes an identification of the external data
source or external server process to be accessed and an account
identifier associated with the application or a user of the
application. The identity map may be searched for a set of
credentials associated with both the account identifier and the
external data source or external server process. The set of
credentials may be transmitted from the authentication server to
the connection server, for the connection server to establish a
connection to the external data source or external server process
and where the connection is for providing the application access to
the external data source or external server process, where the
connection is established without transmitting the set of
credentials to the application.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIGS. 1A and 1B depict example authorization enforcement
strategies.
[0008] FIG. 2 is a block diagram depicting an example configuration
where a connection server and an authentication server manage
access to data.
[0009] FIG. 3 is a block diagram depicting verification of user
credentials at a connection server.
[0010] FIG. 4 is a block diagram depicting example communications
among a connection server, a database server, and a data store.
[0011] FIG. 5 is a block diagram depicting additional example
communications among a connection server, a database server, and a
data store.
[0012] FIG. 6 is a block diagram further depicting communications
between a connection server and an authentication server.
[0013] FIG. 7 depicts contents of an example identity map.
[0014] FIG. 8 depicts contents of another example identity map.
[0015] FIG. 9 is an object type diagram of an example identity map
and its components.
[0016] FIGS. 10A, 10B, and 10C depict example systems for use in
implementing an authentication manager.
DETAILED DESCRIPTION
[0017] FIG. 1A depicts an example authorization enforcement
strategy. In FIG. 1A, an application 102 with which a user or other
program interfaces enforces the data security policies. The
application 102 verifies a user's credentials locally, such as by
verifying a user's username and password. Once the application 102
verifies the credentials, the application 102 accesses a database
server 104 which accesses the desired data in one or more data
stores 106. This configuration may be suboptimal because the
security policies are not centralized. Security policies are
enforced at individual applications, which may exist on many
different physical computers. Such a configuration may be a
security risk and may be difficult to administer.
[0018] FIG. 1B depicts a second example authorization strategy. In
FIG. 1B an application 152 interfaces with a database server 154,
where the database server enforces data security policies using
individual user accounts. The application 152 may receive user
credentials and forward those credentials to the database server
154. The database server 154 may verify the credentials of the
user, and upon verification, the database server 154 may permit
access to the one or more data stores 156. This configuration may
be suboptimal because the security policies are not centralized.
Several database servers (e.g., database server 154) may contain
data desired by the application 152 or other applications. Such a
configuration may be a security risk or may be difficult to
administer.
[0019] Presented herein are general features of identity maps along
with usage scenarios starting at the end-user application. Identity
maps provide the bridge between first and second tier
authentication for a primary server, such as a DataFlux Federation
Server (DFS), to seamlessly connect to and communicate with
secondary servers, such as external database servers configured
within DFS. The primary authentication tier is from the client to
the primary server, and the secondary one is from the primary
server process to one or more secondary servers, typically
preconfigured in primary server metadata.
[0020] The credentials used to authenticate to the secondary
servers may be hidden from the identity authenticated in primary
tier. This security feature incorporated in the identity map design
prevents the primary tier user from directly acquiring the
secondary tier credentials (e.g., a user id and password tuple)
thereby forcing access to the secondary server through the primary
one. This is accomplished by a common authentication server which
helps to centralize authentication administration and runtime
services for applications involving distributed resources across
multiple tiered servers.
[0021] Tiered authentication provides the basis for tiered
authorization enforcement whereby the primary tier enforces
privileges on primary server operations for the primary server
users and the secondary tier enforces privileges on secondary
server operations for the secondary server user. In the case of
DFS, the secondary servers are the backend database servers, and
both DFS and the database servers perform authorization enforcement
for their users. Identity maps provide a secure way to map each
primary server user identity to multiple secondary server
identities where this enforcement can take place in a manageable,
predictable way.
[0022] Identity maps can be employed by any n-level multi-tiered
authentication scheme to hop from one server to the next without
multiple prompts and without regards to server type so long as the
credentials required to authenticate in tier n+1 are available to
the server process and not the connecting client in tier n for each
tier.
[0023] FIG. 2 is a block diagram depicting an example configuration
where a connection server and an authentication server manage
access to data. A user or other application interfaces with a first
application 202. For example, a user may interact with the
application 202 to generate a report. A user may provide user
credentials that entitle that user to access the data needed for
the desired report. The application 202 passes the user credentials
and the data request to a connection server 204.
[0024] Either the application 202 or the connection server 204 may
perform an initial verification of the received user credentials.
If the connection between the connection server 204 and the
authentication server 206 is a trusted connection, then the
authentication server 206 may rely on a connection server's
verification of the user credentials, and the authentication server
206 may not perform an independent verification. If the connection
is not a trusted connection, then the authentication server 206 may
receive and verify the user credentials.
[0025] The connection server 204 and the authentication server 206
interact to provide credentials for the connection server to
establish a connection to the external data source (e.g., data
store 208) based on the verified identity of the user. For example,
an initial connection may be established between the connection
server and the authentication server. This initial connection may
be established using credentials of an identity map manager of one
or more identity maps. This connection may be persisted through
multiple client credential requests.
[0026] Upon receiving the request for data, the connection server
204 provides a credential request to the authentication server 206.
The credential request includes an identification of the external
data source (e.g., data store 208) or external server process to be
accessed and an account identifier associated with the application
202 or a user of the application 202. The authentication server 206
may verify the account or user credentials and may search an
identity map for a set of credentials associated with both the
account identifier and the external data source (e.g., data store
208) or external server process. The authentication server 206 may
transmit a retrieved set of credentials to the connection server
204 for the connection server to establish a connection to the
external data source (e.g., data store 208) or external server
process, such as via database server 210. The connection server may
also access the data store 208 directly. In this manner, the
connection between the application and the external data source
(e.g., data store 208) or external server process can be
established without transmitting the set of credentials to the
application.
[0027] A verification of credential provided by a user may be
provided at a number of stages. FIG. 3 is a block diagram depicting
verification of user credentials at a connection server. A user 302
provides his username 304 and password 306 to an application 308.
The application 308 may verify the credentials, or the application
308 may forward the user name 304 and password 306 to the
connection server 310 for verification. Upon verification of the
username 304 and password 306 at the connection server 310, the
user 302 may subsequently be referenced by a user identifier.
[0028] FIG. 4 is a block diagram depicting example communications
among a connection server, a database server, and a data store. A
connection server 402 provides a user identifier and a database
identifier 404, identifying the database(s) the user wishes to
access, to an authentication server 406. The authentication server
406 accesses credentials 408 for the user to access the database(s)
identified in the message 404 from the connection server and
provides the credentials 408 to the connection server 402. The
connection server 402 provides the credentials 408 to the database
server 410 along with a query 412 for the desired data from one or
more data stores 414. If the credentials 408 provided to the
database server 410 are valid, then the database server 410
accesses the desired data from the one or more data stores 414 and
provides that desired data 416 to the connection server for
subsequent sending to a user or user application.
[0029] FIG. 5 is a block diagram depicting additional example
communications among a connection server, a database server, and a
data store. A single user may be associated with multiple sets of
credentials. All of the users credentials stored in the
authentication server 502 may be associated with a credentials
handle 504. Using a credentials handle 504 may enable a connection
server 506 to quickly request credentials 508 for a user by
referencing the credentials handle 504. Upon an initial access
request, the connection server 506 may provide a username and
password 510 to the authentication server 502 for the owner of the
database credentials. The authentication server 502 may verify the
username and password and provide the credentials handle 504 upon
verification. The connection server 506 may then request individual
credentials 508 for data store 514 accesses using credentials
requests 512 by referencing the data store 514 to be accessed and
the credentials handle 504. Credentials requests 512 may include
other data including user domains, user groups, etc.
[0030] The connection server 506 provides the credentials 508 to
the database server along with a query 516 for the desired data
from one or more data stores 514. If the credentials 508 provided
to the database server 518 are valid, then the database server 518
accesses the desired data from the one or more data stores 514 and
provides that desired data 520 to the connection server for
subsequent sending to a user or user application.
[0031] FIG. 6 is a block diagram further depicting communications
between a connection server and an authentication server. A
connection server 602 provides a user identifier and a database to
access identifier 604 to the authentication server 606. The
authentication server 606 may utilize an identity map 608 to
identify the proper credentials 610 to return to the connection
server 602.
[0032] An identity map 608 may be administrated by an
authentication server administrator 612. Certain of the
configurations described herein may be advantageous because those
implementations offer centralized maintenance of credentials. The
authentication server administrator 612 can add, delete, or update
any data store access credentials at a single location. Such
centralized administration offers numerous security advantages
including fast response to business reality changes (e.g.,
disabling data store access for terminated employees) and avoiding
stale credentials that may occur when credential settings are
spread across multiple physical locations and applications.
Centralized credential maintenance also offers significant
efficiency gains for the authentication server administrator 612.
For example, credentials may be assigned to groups of users as
opposed to individual users, as discussed herein below. In such a
case, an authentication server administrator may greatly limit the
number of credentials that are to be tracked. An authentication
server may centrally hold identity maps for many connection
servers. For example, a collection key may associate the identity
map to the connection server.
[0033] The centralized access provided by an authentication server
offers a number of other advantages as well. For example, a user
may never have access to the raw credentials required to access one
of the data stores. Such a system prohibits unauthorized sharing of
those credentials and offers easy changing or disabling of such
credentials should their security be breached. The centralized
authentication server also offers improved usability for users and
applications because users and applications need only track one set
of individual credentials (e.g., a username and password) for
access to multiple data stores. The specific credentials necessary
for any specific data store access are tracked by the
authentication server and not the user.
[0034] An identity (principal map) may include a number of
features. Example features include: [0035] Ownership: An identity
map may have one owner, a user (identity) previously defined in an
authentication server (AS). Owners may delegate consumption to
managers. [0036] Delegation of management: A complete identity map
has at least one manager, designated by either the user owner or an
AS administrator and optionally additional user and group managers.
Managers may add or remove consumers and may extract the identity
map's outbound identity and password on behalf of any of its
consumers. [0037] Delegation of consumption: A complete identity
map has at least one consumer, designated by either the owner or an
AS administrator. Consumers may access secondary server resources
(available to the outbound identity). [0038] Primary server
association: An identity map is associated with a primary server or
a collaboration of primary servers by a collection key. The
collection key groups all identity maps that are used by a
particular primary server to authenticate to its secondary servers.
[0039] Secondary server association: An identity map is associated
with exactly one secondary server by a domain name. The domain may
correspond to a real domain controller, but always uniquely
identifies an instance of a secondary server to a primary server.
[0040] Application context: In AS users and groups may be scoped to
a particular "application" group through ordinary group membership.
Membership in a particular application group may be specified as a
selection criterion when extracting outbound credentials for an
identity map consumer. An identity may be a consumer of multiple
maps, directly or indirectly, through membership in multiple
application groups. An application group name may be specified at
extract time by the owing application as a means of indirectly
selecting the outbound credentials associated with a particular
secondary server.
[0041] FIG. 7 depicts contents of an example identity map. The
example identity map 702 includes a table having columns
corresponding to a user identifier 704, a data source identifier
706, and data store access credentials 708. Upon receipt of a
credentials request, an authentication server may search the
identity map for a record that contains the user identifier and the
data source identifier contained in the credentials request. The
authentication server may then return the data source access
credentials that correspond with the located record, if such a
record is located.
[0042] FIG. 8 depicts contents of another example identity map. In
the example of FIG. 8, the credentials are organized based on a
group association of an accessing user. The identity map includes
columns corresponding to a user group identifier 804, a data source
identifier 806, and data source access credentials 808. Upon
receipt of a credentials request, an authentication server may
first identify one or more groups with which the requesting user is
associated. The group lookup may also be performed by other
entities, where the credentials request received by the
authentication server may identify one or more user groups. The
authentication server performs a search of the identity map to
identify one or more records that include the group identifier and
the received data source identifier. The authentication server may
then output the data source access credentials associated with
those records. For example, a single user may assume multiple
identities to the same resource.
[0043] FIG. 9 is an object type diagram of an example identity map
and its components. The diagram depicts various features described
herein. Example association ends are labeled with cardinalities
provided. In FIG. 9, type names are in bold, attribute names are in
normal typeface, and object attributes are italicized. The
cardinality shown on the Managers and Consumers associations are
those of a "complete" identity map. The actual cardinality is 0 . .
. n for those associations. However, an identity map normally would
not be without manager or consumers except in a temporary state
while in construction or out of service. Not shown is an ID
attribute that may be common to both Identity and Group objects.
The ID uniquely identifies an instance of an object within AS and
may be used to locate it.
[0044] This written description uses examples to disclose the
invention, including the best mode, and also to enable a person
skilled in the art to make and use the invention. The patentable
scope of the invention may include other examples. For example, in
one example configuration topology, a system may include an
application with connection information such as host and port to
connect to a connection server. A system may further include an
application that is responsible for retrieving credentials from its
users, and passing them to the connection server. A system may
further include a connection server with connection information
such as host and port to connect to an authentication server. The
connection server is configured with one or more credentials (e.g.,
user names/passwords) for connection to the authentication server
for use in retrieving credentials from an identity map. These
credentials are identified as the manager or owner of all identity
maps to be considered when searching for credentials to external
data sources or external server processes.
[0045] The connection server is configured with a collection key,
which is passed on to the authentication server to scope qualifying
identity maps. The connection server is a secured server. Any
server metadata stores are locked down to the connection server
process user and possibly other users operating in administrative
roles. Server configuration may be stored in memory or persisted in
a metadata store.
[0046] Connection servers are configured with connection
information to connect to external data sources and/or external
server processes. Connection metadata may include a consumer group
to uniquely identify an identity map login when multiple identity
maps are available to any application user. The connection server
may additionally implement authorization mechanisms to grant/deny
authenticated users specific actions through the server.
[0047] A system may also include an authentication server which has
the ability to authenticate (verify) user names/passwords.
Additionally, the authentication server is configured with users
(identities), groups/group membership, authenticating logins
(inbound), and logins to external data sources and servers
(outbound). These logins to external resources may be owned by a
user, or an identity map. If an identity map, each map will have
(in addition to the login) a map owner, map consumers (users or
groups who are given permission to use the login), map managers
(users or groups who may read the login in the identity map and
optionally modify the map consumer list), and a collection key map
attribute that identifies map availability to connection servers.
The authentication server is a secured server. Any server metadata
stores are locked down to the authentication server process user
and possibly other users operating in administrative roles (AS
administrators). Server configuration may be stored in memory or
persisted in a metadata store.
[0048] Following is a description of an example system and process
flow for a use of identity maps (e.g., an identity map) to provide
restricted access to a backend server. The SAS DataFlux
Authentication server implements an identity map to give business
application users secure yet granular access to backend databases
while limiting the administrative burden associated with managing
associated DBMS accounts and SQL authorizations. The identity map
object is a flexible user identity mechanism that maps a user
identity authenticated in one domain to a user identity
authenticated in another domain.
[0049] An identity map may be implemented as an identity map
object. This object may consists of the following:
[0050] 1. An association to a single named authentication domain
object. The domain object has attributes that describe how
identities in the specified domain are formed when extracted from
an identity map, as either "userid" or "domain\userid" or
"userid@domain".
[0051] 2. A user identifier (userid) in the authentication
domain.
[0052] 3. A password to be paired with the identity and used to
authenticate to another server in the authentication domain.
[0053] 4. A consumer list. This list identifies the users and
groups who may use the identity to authenticate to another server.
Consumers cannot read the identity or password.
[0054] 5. A manager list. This identifies the users and groups who
may read the identity and password.
[0055] 6. An owner. This identifies the user who may modify the
contents of the identity map.
[0056] A system may further include an identity mapping
authentication server. This server is responsible for
authenticating users and persisting and managing domain objects,
group objects, user objects and identity map objects. The DataFlux
Authentication Server is an example of such a server.
[0057] A system may also include a secured process server that is
responsible for providing application functionality. Such a server
could have many different functions, depending on the application.
It may be responsible for implementing identity maps. It may also
authenticate users through the authentication server and leverage
identity maps to extract credentials for authentication in pier
servers. An example of this server is the DataFlux Federation
Server, which provides secured data access to application
users.
[0058] The following is an example process flow. An application may
require access to a secured server for data or process execution.
The application requires that the user enter credentials. The
application sends the credentials to the Secured Process Server
(SPS). This server uses the authentication server to authenticate
the user. If the user is authenticated, the SPS can perform work as
directed by the user and perform appropriate authorization
enforcement based on the authenticated user identity. If the user
requests services that are delegated through secure backend or pier
servers, the SPS would authenticate to those servers on behalf of
the user by obtaining mapped credentials from identity maps.
[0059] The SPS uses a connection to the authentication server made
by a manager of all identity maps needed to map the SPS users into
user identities in its backend or pier servers. Backend or pier
servers are associated in the SPS with one or more domain names
which are subsequently used to search candidate identity maps for
the user. The remaining filtering is done by confirming the user's
membership in the consumer list and optionally requiring membership
in a particular group in the identity map's consumer list.
Credentials are extracted from matching maps and passed through to
the backend or pier servers for authentication and access to the
delegated services.
[0060] An identity map may be administered according to certain
identity map rules. For example, a shared login owner may have full
control over the identity map's contents, including identifying the
users or groups who may consume the identity or manage the shared
login. The users and groups identified in the manager list may read
the identity from the shared login and modify the consumer
memberships, but may only modify the consumer memberships. This
permits the identity map owner to delegate management of
application users as identity map consumers. The users and groups
identified in the consumer list are used to confirm the
authenticated user's membership, allowing an identity map manager
to extract credentials on their behalf. The domain name is a search
criterion used to locate an identity map for an authenticated
consumer, and a group name is an optional search criterion used to
locate an identity map for an authenticated consumer.
[0061] The following is another example process flow. The DataFlux
Federation Server (DFS) uses the DataFlux Authentication Server
(DAS) to authenticate the connecting user. The DFS manages
connection information to multiple backend DBMS data sources, each
of which is associated with a domain name. The user's connection
string specifies which data sources the user wants to connect to,
but credentials to those data sources are not specified in the
string. The credentials are instead extracted by DFS using a DAS
connection made through a DFS identity maps manager account. This
account belongs to a user that is a member of all identity maps
associated with all the domains configured with the DFS backend
DBMS data sources. The connection string may optionally contain a
GROUP=groupname specification which further qualifies candidate
identity maps for credentials extraction. This process is repeated
for each backend database connection, and the resulting DFS
connection is then able to access SQL data from multiple data
sources without disclosing shared DBMS credentials to the DFS
user.
[0062] SQL authorizations are enforced for the user in the DFS,
simplifying security administration. DFS users cannot connect
directly to the backend data sources since the credentials are
protected in the DAS identity maps created for those users
(consumers). Additionally, the identity maps allow DBMS accounts to
be shared thereby reducing the administrative burden of managing
the backend database servers.
[0063] Following is another example process of using identity maps
in a multi-tiered authentication scheme:
1. A primary server connects to AS using credentials of an identity
who is a common manager of all identity maps with a particular
collection key value. The value identifies the primary server
instance and thus all identity maps configured for use in that
server to establish back-end connections to secondary servers. The
identity map manager identity and password as well as the
collection key itself are preconfigured in the primary server's
metadata or supplied as part of the primary server's startup
parameters. 2. From step 1, an identity handle (ih.sub.m) is
returned to the primary server process and cached for use later
when establishing secondary connections on behalf of primary server
end-users. 3. Steps 1 and 2 occur in the primary server during its
startup sequence. Remaining steps occur per client connection to
the primary server. 4. An application prompts for end-user
credentials (e.g., identity, password tuple) and passes the
credentials as inbound credentials to the primary server along with
a connection name (dsn) and an application group name (g). The
application expects to receive a handle back from the primary
server upon successful connection. 5. The primary server passes
end-user credentials unaltered to AS for authentication and
receives either a failure (possibly authentication related) or an
identity handle (ih.sub.u) for the end-user. Upon successful
authentication, and for each secondary server connection configured
in the named connection (dsn), the primary server makes a
getMappedCredentials( ) call to AS on handle ih.sub.m to extract
the secondary server's credentials (outbound identity, password
tuple). The call includes the primary server's collection key (ck),
the application group name (g), the domain name corresponding to
the secondary server (d.sub.j) and the consumer for which the
secondary server's outbound credentials are to be extracted
(ih.sub.u->id). 6. The getMappedCredentials( )method uses the
tuple (ck, g, d.sub.j, ih.sub.u->id) to locate the identity map
from which the credentials are to be extracted: The end user
identity, uniquely identified in AS by ih.sub.u->id, must
directly or indirectly be a member of the application group, g,
which must directly or indirectly be a consumer of any candidate
maps considered. Candidate maps are further filtered by primary
server's collection key (ck) and secondary server domain (d), both
of which must also match. If the search criteria yield exactly one
identity map, then its credentials are extracted and returned to
the primary server. These remain hidden from the end-user behind
the primary server's process boundary. 7. Credentials for the
secondary server (associated with domain,) and returned in step 6
are used to establish a connection, s.sub.j. The secondary server
connection is added to the end-user connection being constructed by
the primary server, which can be expressed as p=(s.sub.0, s.sub.1,
. . . , s.sub.n-1), an n-way tiered connection. 8. When connections
to all secondary servers are established, the tiered connection
handle (p) is returned from the primary server to the application.
This handle may be used to access data or services from the
secondary servers according to interfaces provided by and
authorization rules enforced on the primary server for the original
end-user identity corresponding to handle ih.sub.u.
[0064] FIGS. 10A, 10B, and 10C depict example systems for use in
implementing an authentication manager. For example, FIG. 10A
depicts an exemplary system 1000 that includes a stand alone
computer architecture where a processing system 1002 (e.g., one or
more computer processors) includes an authentication manager 1004
being executed on it. The processing system 1002 has access to a
computer-readable memory 1006 in addition to one or more data
stores 1008. The one or more data stores 1008 may include an
identity map 1010 as well as user/group mappings 1012.
[0065] FIG. 10B depicts a system 1020 that includes a client server
architecture. One or more user PCs 1022 accesses one or more
servers 1024 running an authentication manager 1026 on a processing
system 1027 via one or more networks 1028. The one or more servers
1024 may access a computer readable memory 1030 as well as one or
more data stores 1032. The one or more data stores 1032 may contain
an identity map 1034 as well as user/group mappings 1036.
[0066] FIG. 10C shows a block diagram of exemplary hardware for a
standalone computer architecture 1050, such as the architecture
depicted in FIG. 10A that may be used to contain and/or implement
the program instructions of system embodiments of the present
invention. A bus 1052 may serve as the information highway
interconnecting the other illustrated components of the hardware. A
processing system 1054 labeled CPU (central processing unit) (e.g.,
one or more computer processors), may perform calculations and
logic operations required to execute a program. A
processor-readable storage medium, such as read only memory (ROM)
1056 and random access memory (RAM) 1058, may be in communication
with the processing system 1054 and may contain one or more
programming instructions for performing the method of implementing
an authentication manager. Optionally, program instructions may be
stored on a computer readable storage medium such as a magnetic
disk, optical disk, recordable memory device, flash memory, or
other physical storage medium. Computer instructions may also be
communicated via a communications signal, or a modulated carrier
wave.
[0067] A disk controller 1060 interfaces one or more optional disk
drives to the system bus 1052. These disk drives may be external or
internal floppy disk drives such as 1062, external or internal
CD-ROM, CD-R, CD-RW or DVD drives such as 1064, or external or
internal hard drives 1066. As indicated previously, these various
disk drives and disk controllers are optional devices.
[0068] Each of the element managers, real-time data buffer,
conveyors, file input processor, database index shared access
memory loader, reference data buffer and data managers may include
a software application stored in one or more of the disk drives
connected to the disk controller 1060, the ROM 1056 and/or the RAM
1058. Preferably, the processor 1054 may access each component as
required.
[0069] A display interface 1068 may permit information from the bus
1056 to be displayed on a display 1070 in audio, graphic, or
alphanumeric format. Communication with external devices may
optionally occur using various communication ports 1072.
[0070] In addition to the standard computer-type components, the
hardware may also include data input devices, such as a keyboard
1072, or other input device 1074, such as a microphone, remote
control, pointer, mouse and/or joystick.
[0071] As additional examples, for example, the systems and methods
may include data signals conveyed via networks (e.g., local area
network, wide area network, internet, combinations thereof, etc.),
fiber optic medium, carrier waves, wireless networks, etc. for
communication with one or more data processing devices. The data
signals can carry any or all of the data disclosed herein that is
provided to or from a device.
[0072] Additionally, the methods and systems described herein may
be implemented on many different types of processing devices by
program code comprising program instructions that are executable by
the device processing subsystem. The software program instructions
may include source code, object code, machine code, or any other
stored data that is operable to cause a processing system to
perform the methods and operations described herein. Other
implementations may also be used, however, such as firmware or even
appropriately designed hardware configured to carry out the methods
and systems described herein.
[0073] The systems' and methods' data (e.g., associations,
mappings, data input, data output, intermediate data results, final
data results, etc.) may be stored and implemented in one or more
different types of computer-implemented data stores, such as
different types of storage devices and programming constructs
(e.g., RAM, ROM, Flash memory, flat files, databases, programming
data structures, programming variables, IF-THEN (or similar type)
statement constructs, etc.). It is noted that data structures
describe formats for use in organizing and storing data in
databases, programs, memory, or other computer-readable media for
use by a computer program.
[0074] The computer components, software modules, functions, data
stores and data structures described herein may be connected
directly or indirectly to each other in order to allow the flow of
data needed for their operations. It is also noted that a module or
processor includes but is not limited to a unit of code that
performs a software operation, and can be implemented for example
as a subroutine unit of code, or as a software function unit of
code, or as an object (as in an object-oriented paradigm), or as an
applet, or in a computer script language, or as another type of
computer code. The software components and/or functionality may be
located on a single computer or distributed across multiple
computers depending upon the situation at hand.
[0075] It should be understood that as used in the description
herein and throughout the claims that follow, the meaning of "a,"
"an," and "the" includes plural reference unless the context
clearly dictates otherwise. Also, as used in the description herein
and throughout the claims that follow, the meaning of "in" includes
"in" and "on" unless the context clearly dictates otherwise.
Finally, as used in the description herein and throughout the
claims that follow, the meanings of "and" and "or" include both the
conjunctive and disjunctive and may be used interchangeably unless
the context expressly dictates otherwise; the phrase "exclusive or"
may be used to indicate situation where only the disjunctive
meaning may apply.
* * * * *