Certificate-based client authentication and authorization for automated interface

A method and system provide the ability to authenticate client services. A private key and a client certificate are created and delivered to a client. Based on the private key and the certificate, a client account is created for the client on a server. One or more signing or feature licensing configurations are created and authorized on the server for the client account. The client certificate and a request to perform a requested client service are received on the server from a client. The request includes configuration information for the requested client service. The server verifies the client certificate and determines whether the client is authorized to perform the requested client service. The determination is based on the configuration information and the one or more authorized client operations. Upon determining that the client is authorized to perform the requested client service, the request is processed the authorization is sent to the client. Upon a determination that the client is not authorized to perform the requested client service, the requested client service is denied.

BACKGROUND

The present disclosure relates to systems and methods for signing, encrypting and/or decrypting data for use on devices, and in particular to a system and method for authenticating and authorizing client services.

2. Description of the Related Art

Client devices often provide a variety of services ranging from distributing, installing, and updating code (e.g., onto field client devices) to licensing software. To ensure adequate security and that the services are not received from or being executed by unauthorized sources, authentication and security is required. However prior art authentication and security systems may be inadequate and/or fail to provide the level of customization/configuration that is desired. To better understand such problems of the prior art, a description or prior art client authentication and authorization services may be useful.

It is beneficial in some circumstances to provide data to devices which have already been distributed to end users (e.g. fielded devices). Such data may be needed to update the device(s) to newer configurations or to perform additional functions, to ameliorate software “bugs” or other issues, or to simply replace data already resident in the device that may have been compromised. Such data may include software instructions (e.g. code) to update fielded devices by providing data such as software code to those devices remotely.

One of the problems with the remote downloading of such data to fielded devices is that the data may be from an unauthorized source. An entity providing the data to the fielded devices may pose as a legitimate source of the data, yet provide data that is designed to compromise the security or functionality of the device. For example, the user of the device may be misled into believing that their device needs a software update in order to function properly, and may be provided a bogus uniform resource location (URL) from which to download the software update. If the user downloads and installs the software update from the bogus URL, the code that is actually downloaded may include a virus or other malware that negatively affects the operation of the device, perhaps compromising all of the data (including the user's private information) that was stored by the device before the infected.

To prevent the foregoing problems, code signing techniques can be used to digitally sign data such as executables and scripts. Such signatures confirm the identity of the author of the data and guarantee that the data has not been altered or otherwise corrupted since it was signed. Most code signing paradigms provide a digital signature mechanism to verify the identity of the author of the data or build system, and a checksum to verify that the data object has not been modified. Such code signing paradigms typically use authentication mechanisms such as public key infrastructure (PKI) technologies, which rely on data publishers securing their private keys against unauthorized access. The public key used to authenticate the data signature should be traceable back to a trusted root certificate authority (CA). If the data signature is traced to a CA that the device user trusts, the user is presumed to be able to trust the legitimacy and authorship of the data that is signed with a key generated by that CA. Such a system is referred to as a chain of trust and refers to the concept such that if the issuing CA is trusted and the chain can be traced to a trusted root certificate from that issuing CA, the entire chain is trusted and no further information/authentication is performed. However, it is undesirable to simply rely on a base trusted root certificate.

Systems for code signing are known in the art. However, such prior art code signing systems do not provide a framework that allows different organizations or companies to structure their data signing permission needs as they see fit or to safely permit data signing by other independent organizations. In other words, there may be a need/desire to customize the configuration and authentication of a software system. For example, assume Company A produces a set top box that can use a chip that can execute software from Company1or Company2. Company A may desire to establish a data signing framework that allows Company1to sign data that it installs into their set top boxes, without providing Company2with access to that data signing framework. Similarly, Company A may desire to establish a data signing framework that allows Company2to establish a data signing framework that excludes (or includes) Company1. In another example, a particular client/software provider may need to update a particular feature of a software application based on the type of end user within an organization (e.g., an administrator may be have feature while another user may have a different or fewer features). Accordingly, it is desirable to utilize a more flexible/configurable system than that of a chain based authentication system or other system of the prior art.

Alternative prior art code signing systems include the issuance of USB crypto tokens (i.e., hardware dongles) for authentication. However, the use of hardware tokens is undesirable in some scenarios.

In addition to code signing, feature licensing systems require authentication and configurable licenses for certain clients and subcategories within a client (e.g., types of users). However, prior art feature licensing systems lack configurability while ensuring security without the use of a hardware token/dongle.

In view of the above, what is needed is a system and method that provides a configurable system for the management, authentication and authorization of client services for code or configuration signing and encryption.

SUMMARY OF THE INVENTION

Embodiments of the invention overcome the problems of the prior art by providing an automated client service application that authenticates a client and authorizes a requested client service without using hardware encryption token/dongles. Embodiments utilize a client certificate that includes configuration information to provide a flexible system. In particular, a code signing server is configured with a service/operation configuration on a per/client account basis. Upon receipt of a service application request received from a client, the code signing server verifies a client certificate, checks the authorization of the client (via the service/operation configuration), and generates an appropriate authorization or authorization denial that is transmitted to the client service application via a secure communication protocol.

More specifically, embodiments of the invention provide the ability to authenticate client services. A private key and a client certificate are created for a client service application. The private key and the client certificate are delivered to and installed in an environment of the client service application. Based on the private key and the certificate, a client account is created for the client service application on a server. One or more authorized client operations are defined on the server for the client account. The client certificate and a request to perform a requested client service are received, from the client service application on the server. The request includes a server configuration identifier for the requested client service. The server verifies the client certificate at an application layer and extracts a client account ID from the client certificate. A determination is made regarding whether the client account corresponding to the client service application is authorized to perform the requested client service. Such a determination is based on the client account ID and configuration information associated with the server configuration identifier. Upon determining that the client account is authorized to perform the requested client service, the request is processed and an authorization is sent to the client service application. Upon determining that the client account is not authorized to perform the requested client service, requested client service is denied.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanying drawings which form a part hereof, and which is shown, by way of illustration, several embodiments. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present disclosure.

Overview

Embodiments of the invention provide the ability to authenticate a client in a client-server model that does not utilize client-side hardware encryption (e.g., a token/dongle) in a configurable manner. Embodiments of the invention may be utilized in any system where client services are being provided including a code signing service or feature licensing system (e.g., providing licensing generation) that may be implemented in the cloud network. Note that “code signing service” in this description refers to various cryptographic operations in general, including code signing, code encryption, code obfuscation, hashing, and any combinations of these operations.

Architectural System/Logical Flow

FIG. 1illustrates the architecture and logical flow for authenticating client services/a client in accordance with one or more embodiments of the invention. The flow in system100is represented by steps102-114performed by system components116-122.

At step102A, an administrator124uses a CA system116(i.e., a system that issues certificates from the assignee of the present application) to create a certificate and private key for a client service application118. Such a client may be bound to a single physical computer or it may be instantiated one or more times in a cloud based system.

At step104, the certificate and key are delivered to the client service application118in an encrypted format. Embodiments of the invention are not limited to a particular protection format/methodology. In this regard, any type of encrypted format may be used including password protection, public-private key encryption, hardware token/dongle, etc.

At step106, the private key and certificate are installed into the environment of a client service application118. The client service application118may include an implementation of an application programming interface (API) specified by a server entity.

At step102B (which may be executed in parallel or shortly after step102A), a client account is created on a code signing server120based on the created certificate and key. Such a step may be a manual operation where the administrator124creating the certificate on the CA system116comes into the code signing server120and sets up the account. Such an account creates a client account126with the newly created certificate such that the code signing server120recognizes there is a new client account126. The code signing server120treats client account126similar to human user accounts and assigns it code signing privileges in a similar manner.

At step108, a project administrator128authorizes the client account126to perform particular operations (e.g., using the client service application118) on the code signing server120. In this regard, in step108, the code signing server120simply establishes the permissions for the operations that the client account126is authorized to perform. In this regard, while step102B registers the client account126, the client account may not be authorized, by default, to perform all operations. Instead, the permissions/authorizations are also delineated/defined at step108. Further, the client service application118associated with the client account126may not perform/provide any services prior to defining the permissions/authorization.

Steps110-112are the steps performed each time the client service application118performs an operation requiring authentication. The communication between the client service application118and the code signing server120may be performed via a two-way (2-way) transport layer security (TLS) connection122. To define the 2-way TLS connection122, both the client service application118and server mutually authenticate each other (referred to as a handshake). For example, the server may authenticate the client service application118using the client certificate that is issued in step102A and installed at step106, and the client service application118may authenticate the server using the server certificate presented by the server during the TLS handshake to ensure that the client is not communicating with a compromised server. Note that the client is pre-configured with the root certificate that the server certificate is issued from.

At step110, the client service application118transmits a request to perform an operation to the code signing server120. The request110may include the specific configuration for the operation to be performed (e.g., an indicator as to the operation to be performed so that the server120knows what is being requested). In an exemplary embodiment of a code signing operation, the request110may consist of a signing request (e.g., that includes the code to be signed or a code hash). The signing request itself may consist of a signing configuration identifier (also referred to as request configuration, where the corresponding configuration with this identifier stored on the server includes the operation for which authorization is requested and further configuration details). As part of the configuration (or separate from), the client account126ID may be provided. However, the identity of the client account126may already be provided during the two-way TLS handshake such that the identity (within the client certificate) may be provided to the server120during the handshake (so that the client service application118may not need to provide a client account ID again with the request110). On the other hand, client service application118may provide additional client identity information such as client type, physical user name responsible for administering the client service application118, client site information, etc. for server's logging purpose. This additional informational client information provided will not be used to determine if a client is authorized, but may be useful in troubleshooting and debugging use.

At step112, in response to the request110(which includes the request configuration) the server120verifies the client certificate, checks the authorization of the client service application118based on the request configuration, and generates a response (e.g., an authorization or a rejection). In other words, at step112, the server120checks to see if the client account126associated with the client service application118is indeed authorized for the particular requested operation (based on the authorization defined in step108). In one or more embodiments, the server120performs an additional authentication of the client service application118by extracting the certificate from the lower transport layer (i.e., from the TLS connection122) and verifying the client certificate once again. In this regard, the different layers referred to herein refer to the open systems interconnection model (OSI model) that partitions a communication system into abstraction layers (i.e., application layer, presentation layer, session layer, transport layer, network layer, data link layer, and physical layer).

Once the client service application118is authenticated and the authorization is confirmed, the request110is processed by generating a response that is transmitted back to the client service application118. Accordingly, at step114, the response is transmitted back to the client service application118. In an exemplary embodiment of a code signing request, the response may consist of a code signature. The client service118may perform additional post processing to form the final signed code image. For example, the code signature is combined (concatenated) with the code image.

Additional Embodiments

Authentication

As described above, the client and server may mutually authenticate using two-way TLS122. In addition, the server may also verify the client certificate (e.g., that has been extracted from the transport layer) at the application layer and extract the client account ID from the certificate to check authorization for signing. In this regard, the client account ID is typically in the subject name of the certificate (e.g., the Common Name field). Further, TLS122is typically handled by a network stack such as WINDOWS IIS (Internet Information Services). For example, the application may need to extract the TLS certificate from the network stack to perform the extra verification and authorization. Typically, the server may be configured with multiple trusted root CAs, but each signing configuration needs to be explicitly authorized for a particular client certificate. Thus, step112authenticates the client service application118(using the client certificate) and then compares the configuration-client account pair to the authorizations defined at step108.

In one or more additional embodiments, instead of or in addition to TLS122(or IPSec [Internet Protocol Security]), mutual authentication may be achieved at the application level. For example, the request messages110may be signed by the client service application118using a client private key, while response messages are signed by the server. Thereafter, both sides may verify the signatures on the received messages before proceeding. Thus, one-way TLS authentication may be utilized where a client service application118is authenticated at a server during a TLS session after which the client presents a certificate and establishes its identify by signing the request message at the application level.

Automated API Control

Each signing configuration defined at the code signing server may have a flag to control if an automated API (such as a Restful API) utilizing the certificate-based client authentication is enabled or not. In this regard, using a client certificate (of embodiments of the invention) instead of a hardware token for client authentication may be considered lower in security. As a result, it may be desirable to control use of the automated API on a per configuration basis such that code signing with higher security requirements, such as boot code signing, may not be enabled for automated code signing using certificate-based client authentication. In such embodiments, each configuration may need to be explicitly authorized to enable the client certificate-based automated API. Such a control may be extended to a per company-basis, so that the client certificate-based automated API can only be enabled for certain companies. Regardless of whether the automated API is enabled/disabled, each time a client service application118desires to perform a new/different operation, a new request110(that includes the configuration for the new request) is transmitted and the steps112-114are performed. In this regard, session management based on whether a API is enabled or disabled is a separate process.

Automated Interface

Step102B may be replaced by an automated interface. In such embodiments, when the CA system116issues a new client certificate intended for the code signing server120use, the certificate will be automatically (autonomously without additional user input) forwarded to the code signing server120, and a new client account will be created as a result. Alternatively, the code signing server120may periodically poll the CA system116for newly issued client certificates and create a client account accordingly.

Access Management

Permission for a client account may be granted/removed on individual, multiple, or all configurations within the code signing server120. In other words, embodiments of the invention provide flexibility in the management of client authorizations (e.g., permissions/authorizations for a client account may be changed/updated within the code signing server120). For example, a client account126may be deactivated from a system, and once deactivated, the corresponding client service application118will not be able to access any configuration. In addition, a client certificate may be revoked thereby resulting in a revocation of access (i.e., a response authorizing an operation would not be granted transmitted at step114).

Exemplary Embodiments

As described above, embodiments of the invention may be utilized to provide authorization for any client service application. Exemplary embodiments include a code signing service as well as a feature licensing system (i.e., a client authorization for individual license configurations). In a feature licensing system, different configurations may be utilized to provide different levels of authorization/access. For example, authorization to access API functions may be based on client types. In addition to function level access authorization for different client types and API level access authorization for different configurations (e.g., signing configuration or licensing configuration), embodiments of the invention may also control which configuration can use which functions.

To provide flexibility, embodiments may include additional information in a client certificate. For example, client account ID included in the client certificate may include identifying information for both the type of client service application118and also a client instance ID which identifies a specific installation of that client (e.g., at a particular customer location or on a particular customer client machine). Further, another signing/licensing configuration level option may include whether to enforce the matching between the client instance ID in the client certificate and the one in the request. In this regard, there may be multiple instances of a client service application118installed within a network and a client certificate may be specific to a particular instance which is provided with additional authorization for additional code signing configuration(s). When a request110(that contains the additional client instance ID information) is transmitted to the code signing server120, the client instance ID information may be used to allow the server120to conduct such additional checking/verification to confirm that the certificate is being used in accordance with the defined permissions (e.g., at step108). Further to the above, authorizations may be specified at varying levels (e.g., different clients, different installations within a client, etc.). In further embodiments, any type of information may be included in the client certificate such that any type or level of authorization may be specified and verified.

In addition to the above, embodiments of the invention may be used for any automated services, not just code signing or feature licensing.

General Logical Flow

In addition to the description and flow described above,FIG. 2illustrates the logical flow for authenticating client services in accordance with one or more embodiments of the invention.

At step202, a private key and a client certificate are created for a client service application.

At step204, the private key and the client certificate are delivered to the client service application. The private key and the client certificate may be delivered either directly to the client service application or to its administrator in an encrypted format. Once received by an administrator, the private key and the client certificate are installed into the environment of the client service application.

At step206, based on the private key and the certificate, a client account is created/defined for the client service application on a server. Alternatively, upon creation of the client certificate at step202, the client certificate is automatically/autonomously forwarded to the server (in step204) triggering the automatic creation of the client account (without human interaction) at step206. In alternative embodiments, the server may periodically poll (the CA authority) for newly created client certificates, and upon determining that the client certificate has been created, the server autonomously and automatically creates the client account.

At step208, on the server, the client account is authorized for one or more configurations. In other words, one or more authorized client operations are defined for the client account. The configurations may have already been defined at an earlier stage. For a code signing service, the configuration information consists of signing configuration parameters, including the cryptographic operations, signing and/or encryption keys, and any other parameters needed to complete the operations.

In alternative embodiments, the function of the client service is to obtain a signed license file with a list of features and capabilities for which a target system is authorized. Server configurations in this case may consist of either binary flags (to turn a feature on or off) or counted features (e.g., maximum number of users allowed). Thus, the configuration information may include licensing configuration parameters for one or more software or hardware features.

At step210, the client certificate and a request to perform a requested client service are received (from the client service application on the server). The request includes a server configuration identifier for the requested client service. Step210may also include establishing a two-way transport layer security (TLS) connection between the client service application and the server. The client service application and the server would mutually authenticate using the TLS connection, and the client certificate is received inside a TLS handshake during step210.

At step212, the server verifies the client certificate—as part of a TLS handshake, at application layer or both. Further, step212includes extracting a client account ID from the client certificate.

At step214, the server determines whether the client (e.g., the client account corresponding to the client service application) is authorized to perform the requested client service. Such a determination is based on the client account ID and configuration information associated with the server configuration identifier. In one or more embodiments, the server verifies the client certificate at an application layer (at step212) and extracts a client account ID from the client certificate to check authorization (at step214). Steps212-214may also include controlling whether the client certificate-based automated application programming interface (API) has been enabled for the client via a flag in the configuration information defined on the server.

At step216, upon determining that the client is or is not authorized to perform the requested client service, the request is processed and the client service application either receives a successful result of the requested operation or a denial indicator.

Hardware Environment

FIG. 3is an exemplary hardware and software environment300(referred to as a computer-implemented system and/or computer-implemented method) used to implement one or more embodiments of the invention. The hardware and software environment includes a computer302and may include peripherals. Computer302may be a user/client computer, server computer, or may be a database computer. The computer302comprises a hardware processor304A and/or a special purpose hardware processor304B (hereinafter alternatively collectively referred to as processor304) and a memory306, such as random access memory (RAM). The computer302may be coupled to, and/or integrated with, other devices, including input/output (I/O) devices such as a keyboard314, a cursor control device316(e.g., a mouse, a pointing device, pen and tablet, touch screen, multi-touch device, etc.) and a printer328. In one or more embodiments, computer302may be coupled to, or may comprise, a portable device332(e.g., cellular device, tablet computer, personal digital assistant, etc.). In yet another embodiment, the computer302may comprise a multi-touch device, mobile phone, gaming system, internet enabled television, television set top box, or other internet enabled device executing on various platforms and operating systems.

In one embodiment, the computer302operates by the hardware processor304A performing instructions defined by the computer program310(e.g., a client service application and/or code signing server) under control of an operating system308. The computer program310and/or the operating system308may be stored in the memory306and may interface with the user and/or other devices to accept input and commands and, based on such input and commands and the instructions defined by the computer program310and operating system308, to provide output and results.

Output/results may be presented on the display322or provided to another device for presentation or further processing or action. In one embodiment, the display322comprises a liquid crystal display (LCD) having a plurality of separately addressable liquid crystals. Alternatively, the display322may comprise a light emitting diode (LED) display having clusters of red, green and blue diodes driven together to form full-color pixels. Each liquid crystal or pixel of the display322changes to an opaque or translucent state to form a part of the image on the display in response to the data or information generated by the processor304from the application of the instructions of the computer program310and/or operating system308to the input and commands. The image may be provided through a graphical user interface (GUI) module318. Although the GUI module318is depicted as a separate module, the instructions performing the GUI functions can be resident or distributed in the operating system308, the computer program310, or implemented with special purpose memory and processors.

In one or more embodiments, the display322is integrated with/into the computer302and comprises a multi-touch device having a touch sensing surface (e.g., track pod or touch screen) with the ability to recognize the presence of two or more points of contact with the surface. Examples of multi-touch devices include mobile devices (e.g., IPHONE, NEXUS S, DROID devices, etc.), tablet computers (e.g., IPAD, HP TOUCHPAD, SURFACE Devices, etc.), portable/handheld game/music/video player/console devices (e.g., IPOD TOUCH, MP3 players, NINTENDO SWITCH, PLAYSTATION PORTABLE, etc.), touch tables, and walls (e.g., where an image is projected through acrylic and/or glass, and the image is then backlit with LEDs).

Some or all of the operations performed by the computer302according to the computer program310instructions may be implemented in a special purpose processor304B. In this embodiment, some or all of the computer program310instructions may be implemented via firmware instructions stored in a read only memory (ROM), a programmable read only memory (PROM) or flash memory within the special purpose processor304B or in memory306. The special purpose processor304B may also be hardwired through circuit design to perform some or all of the operations to implement the present invention. Further, the special purpose processor304B may be a hybrid processor, which includes dedicated circuitry for performing a subset of functions, and other circuits for performing more general functions such as responding to computer program310instructions. In one embodiment, the special purpose processor304B is an application specific integrated circuit (ASIC).

The computer302may also implement a compiler312that allows an application or computer program310written in a programming language such as C, C++, Assembly, SQL, PYTHON, PROLOG, MATLAB, RUBY, RAILS, HASKELL, or other language to be translated into processor304readable code. Alternatively, the compiler312may be an interpreter that executes instructions/source code directly, translates source code into an intermediate representation that is executed, or that executes stored precompiled code. Such source code may be written in a variety of programming languages such as JAVA, JAVASCRIPT, PERL, BASIC, etc. After completion, the application or computer program310accesses and manipulates data accepted from I/O devices and stored in the memory306of the computer302using the relationships and logic that were generated using the compiler312.

In one embodiment, instructions implementing the operating system308, the computer program310, and the compiler312are tangibly embodied in a non-transitory computer-readable medium, e.g., data storage device320, which could include one or more fixed or removable data storage devices, such as a zip drive, floppy disc drive324, hard drive, CD-ROM drive, tape drive, etc. Further, the operating system308and the computer program310are comprised of computer program310instructions which, when accessed, read and executed by the computer302, cause the computer302to perform the steps necessary to implement and/or use the present invention or to load the program of instructions into a memory306, thus creating a special purpose data structure causing the computer302to operate as a specially programmed computer executing the method steps described herein. Computer program310and/or operating instructions may also be tangibly embodied in memory306and/or data communications devices330, thereby making a computer program product or article of manufacture according to the invention. As such, the terms “article of manufacture,” “program storage device,” and “computer program product,” as used herein, are intended to encompass a computer program accessible from any computer readable device or media.

FIG. 4schematically illustrates a typical distributed/cloud-based computer system400using a network404to connect client computers402to server computers406. A typical combination of resources may include a network404comprising the Internet, LANs (local area networks), WANs (wide area networks), SNA (systems network architecture) networks, or the like, clients402that are personal computers or workstations (as set forth inFIG. 3), and servers406that are personal computers, workstations, minicomputers, or mainframes (as set forth inFIG. 3). However, it may be noted that different networks such as a cellular network (e.g., GSM [global system for mobile communications] or otherwise), a satellite based network, or any other type of network may be used to connect clients402and servers406in accordance with embodiments of the invention.

A network404such as the Internet connects clients402to server computers406. Network404may utilize ethernet, coaxial cable, wireless communications, radio frequency (RF), etc. to connect and provide the communication between clients402and servers406. Further, in a cloud-based computing system, resources (e.g., storage, processors, applications, memory, infrastructure, etc.) in clients402and server computers406may be shared by clients402, server computers406, and users across one or more networks. Resources may be shared by multiple users and can be dynamically reallocated per demand. In this regard, cloud computing may be referred to as a model for enabling access to a shared pool of configurable computing resources.

Clients402may execute a client application or web browser and communicate with server computers406executing web servers410. Such a web browser is typically a program such as MICROSOFT INTERNET EXPLORER/EDGE, MOZILLA FIREFOX, OPERA, APPLE SAFARI, GOOGLE CHROME, etc. Further, the software executing on clients402may be downloaded from server computer406to client computers402and installed as a plug-in or ACTIVEX control of a web browser. Accordingly, clients402may utilize ACTIVEX components/component object model (COM) or distributed COM (DCOM) components to provide a user interface on a display of client402. The web server410is typically a program such as MICROSOFT'S INTERNET INFORMATION SERVER (IIS).

Web server410may host an Active Server Page (ASP) or Internet Server Application Programming Interface (ISAPI) application412, which may be executing scripts. The scripts invoke objects that execute business logic (referred to as business objects). The business objects then manipulate data in database416through a database management system (DBMS)414. Alternatively, database416may be part of, or connected directly to, client402instead of communicating/obtaining the information from database416across network404. When a developer encapsulates the business functionality into objects, the system may be referred to as a component object model (COM) system. Accordingly, the scripts executing on web server410(and/or application412) invoke COM objects that implement the business logic. Further, server406may utilize MICROSOFT'S TRANSACTION SERVER (MTS) to access required data stored in database416via an interface such as ADO (Active Data Objects), OLE DB (Object Linking and Embedding DataBase), or ODBC (Open DataBase Connectivity).

Although the terms “user computer”, “client computer”, and/or “server computer” are referred to herein, it is understood that such computers402and406may be interchangeable and may further include thin client devices with limited or full processing capabilities, portable devices such as cell phones, notebook computers, pocket computers, multi-touch devices, and/or any other devices with suitable processing, communication, and input/output capability.

Of course, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, may be used with computers402and406. Embodiments of the invention are implemented as a software application on a client402or server computer406. Further, as described above, the client402or server computer406may comprise a thin client device or a portable device that has a multi-touch-based display.

CONCLUSION

This concludes the description of the preferred embodiments of the present disclosure. The following describes some alternative embodiments for accomplishing the present invention. For example, any type of computer, such as a mainframe, minicomputer, or personal computer, or computer configuration, such as a timesharing mainframe, cloud computing system, local area network, or standalone personal computer, could be used with the present invention.

In addition, advantages of embodiments of the invention differ from prior art certificate chain trust implementations while also not requiring hardware token/dongles. Embodiments of the invention are configurable as additional information is set forth/defined in a client certificate that may be used for additional authentication/verification, as well as for authorization of different services based on different clients/client types.

The foregoing description of the preferred embodiment has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of rights be limited not by this detailed description, but rather by the claims appended hereto.