US20110214165A1

US20110214165A1 - Processor Implemented Systems And Methods For Using Identity Maps And Authentication To Provide Restricted Access To Backend Server Processor or Data

Info

Publication number: US20110214165A1
Application number: US13/034,323
Authority: US
Inventors: David Kerr Jeffreys; Robert Brian Hess
Original assignee: SAS Institute Inc
Current assignee: SAS Institute Inc
Priority date: 2010-02-26
Filing date: 2011-02-24
Publication date: 2011-09-01
Also published as: US20110213778A1; US8645386B2

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

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

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.
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.
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

FIGS. 1A and 1B depict example authorization enforcement strategies.

FIG. 2 is a block diagram depicting an example configuration where a connection server and an authentication server manage access to data.

FIG. 3 is a block diagram depicting verification of user credentials at a connection server.

FIG. 4 is a block diagram depicting example communications among a connection server, a database server, and a data store.

FIG. 5 is a block diagram depicting additional example communications among a connection server, a database server, and a data store.

FIG. 6 is a block diagram further depicting communications between a connection server and an authentication server.

FIG. 7 depicts contents of an example identity map.

FIG. 8 depicts contents of another example identity map.

FIG. 9 is an object type diagram of an example identity map and its components.

FIGS. 10A, 10B, and 10C depict example systems for use in implementing an authentication manager.

DETAILED DESCRIPTION

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
An identity (principal map) may include a number of features. Example features include:

- Ownership: An identity map may have one owner, a user (identity) previously defined in an authentication server (AS). Owners may delegate consumption to managers.
- 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.
- 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).
- 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.
- 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.
- 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.

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.
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.
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.
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.
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.
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.
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.
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.
An identity map may be implemented as an identity map object. This object may consists of the following:
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”.
2. A user identifier (userid) in the authentication domain.
3. A password to be paired with the identity and used to authenticate to another server in the authentication domain.
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.
5. A manager list. This identifies the users and groups who may read the identity and password.
6. An owner. This identifies the user who may modify the contents of the identity map.
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.
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.
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.
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.
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.
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.
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.
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_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_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_mto 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_j) and the consumer for which the secondary server's outbound credentials are to be extracted (ih_u->id).
6. The getMappedCredentials( )method uses the tuple (ck, g, d_j, ih_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_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_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₀, s₁, . . . , s_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_u.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

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;

10. The system of claim 8, wherein the identity map is modified based on authentication information received from an authentication server administrator;

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;

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

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: