GB2325314A - Object-oriented system for authentication - Google Patents
Object-oriented system for authentication Download PDFInfo
- Publication number
- GB2325314A GB2325314A GB9709532A GB9709532A GB2325314A GB 2325314 A GB2325314 A GB 2325314A GB 9709532 A GB9709532 A GB 9709532A GB 9709532 A GB9709532 A GB 9709532A GB 2325314 A GB2325314 A GB 2325314A
- Authority
- GB
- United Kingdom
- Prior art keywords
- server
- processing device
- processing
- client
- authentication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
Abstract
A key server, for authentication in a client/server computing network where a client processing device requests a working server processing device to perform a processing task is implemented in object-oriented software. Thus, the steps of receiving an authentication request (301) from a processing device processing the authentication request (302-306) and informing the requesting device of the result of the processing (307) are performed by invoking methods onto objects.
Description
OBJECT-ORIENTED COMPUTER AUTHENTICATION METHOD,
APPARATUS AND COMPUTER PROGRAM PRODUCT
Field of the Invention
The present invention relates to the field of data processing and more particularly to security systems for use in data processing so that a potential user of data processing resources must prove his identity before he is granted access to the resources.
Background of the Invention
Client/server computing has become more and more important over the past few years in the information technology world. This type of distributed computing allows one machine to delegate some of its work to another machine that might be, for example, better suited to perform that work. For example, the server could be a high-powered computer running a database program managing the storage of a vast amount of data, while the client is simply a desktop personal computer (PC) which requests information from the database to use in one of its local programs.
In client/server systems, it is important that access to the servers be protected so that only authorized clients can obtain access to server resources. A well known software product known as Kerberos has been developed by the Massachusetts Institute of Technology in Cambridge,
Massachusetts in the United States of America for meeting this goal ("Kerberos" is a trademark of the Massachusetts Institute of Technology).
According to Kerberos, all clients and servers on the network store their identification and password data confidentially with a central server known as a key server. This key server acts as an intermediary between clients and servers and only allows a client to access a server if the client can prove to the key server that the client is who he says he is.
The Kerberos software is a monolithic program written in a procedural programming language. The software program is very long and detailed as most of the software code portions are dedicated to providing the communications infrastructure for allowing the clients and servers to communicate with the key server. A small percentage of the total software code portions is dedicated to the actual Kerberos implementations of the authentication functions and these portions are intermingled with the above-mentioned code portions related to implementing the communications infrastructure.
Therefore, once the Kerberos software has been written, it is very difficult to add more function to the code. The Kerberos functional software is dedicated to performing the specific function originally intended and these functions are intermingled with the majority of the overall Kerberos software code that is dedicated to the communications infrastructure, thus making the functional software portions very difficult to edit.
Disclosure of the Invention
According to one aspect, the present invention provides an authentication server for use in a client/server computing network where a client processing device requests a working server processing device to perform a processing task, the authentication server comprising: means for receiving an authentication request from a processing device; means for processing the authentication request; and means for informing the processing device of the result of said means for processing; wherein said authentication server is embodied in objectoriented software.
According to a second aspect, the invention provides a method of providing authentication of a processing device using an authentication server, with the method including steps analogous to the elements of the authentication server discussed above with respect to the first aspect of the invention.
According to a third aspect, the invention provides a computer program product stored on a computer readable storage medium (such as a hard drive, CD-ROM, magneto-optical disk or floppy disk) having computer software code portions for performing the functionality specified above with respect to the elements of the authentication server of the first aspect of the invention.
Accordingly, as the Kerberos functional aspects are easily separable from the remaining parts of the server software, editing (e.g., adding new functionality to) the functional Kerberos software is greatly facilitated.
Brief Description of the Drawings
Figure 1 shows the object class hierarchy according to a preferred embodiment of the present invention;
Figure 2 is a block diagram of the arrangement of client/server elements according to a preferred embodiment of the present invention;
Figure 3 is a flowchart showing the steps taken by the key server according to a preferred embodiment of the present invention; and
Figure 4 is a block diagram of the arrangement of client/server elements according to a second preferred embodiment of the present invention.
Detailed Description of the Preferred Embodiments
The benefits of client/server computing have been further enhanced by the use of a well-known computer programming technology called objectoriented programming (OOP), which allows the client and server to be located on different (heterogeneous) "platforms" and greatly facilitates communication amongst such clients and servers. A platform is a combination of the specific hardware/software/operating system/communication protocol which a machine uses to do its work. OOP allows the client application program and server application program to operate on their own platforms without worrying how the client application's work requests will be communicated and accepted by the server application. Likewise, the server application does not have to worry about how the OOP system will receive, translate and send the server application's processing results back to the requesting client application.
According to a preferred embodiment of the present invention, one of these object-oriented servers has software code added to it so that it performs the Kerberos key server functionality with respect to other clients and servers in the network. As the server software is written in object-oriented form, the addition of the Kerberos functionality involves simply adding a few extra object classes as will be explained below.
With reference to Fig. 1, a principal class 1, called "secure~base", is first defined and two sub-classes "user" and "server" (2 and 3, respectively) of this principal class are then defined. Each sub-class 2 and 3 inherits the methods and attributes of the principal class 1, as is well-known in QO programming.
Instances of the "user" and "server" sub-classes are created in an object-oriented server 23 (see Fig. 2) which acts as the Kerberos key server with respect to a client 21 which is requesting access to files stored at a file server 22, with the client 21, file server 22 and server 23 all being connected to the same network. According to the Kerberos system, the client 21 is not allowed to transmit a request to file server 22 (to retrieve a document, for example) until the client 21 has proved its identity to the trusted key server (implemented within server 23).
Also, the file server 22 is not allowed to respond to a request from client 21 until the file server 22 has proved its identity to the key server.
The following functionality is carried out by the Kerberos key server implemented in server 23 with reference to the flowchart of Fig.
3. In a preliminary step (not shown in Fig. 3) the client 21 invokes a locate method on some well-known object, such as the Object Request
Broker of server 23 along line 211 of the network, and then gets back an object reference to the "user" object 2 which will represent client 21 within the key server 23. At step 301 the "user" object 2 receives an invocation request of its "login()" method from client 21. This method, which does not have any parameters, is invoked by client 21 upon the user object 2 to signify that the client 21 wishes to authenticate itself.
Upon receiving this request, the "user" object 2 returns a challenge to client 21. As is well known according to the Kerberos algorithm, this challenge could be two random numbers that the client 21 must add together, each of the two numbers being encrypted on the client 21's password.
After solving the challenge and encrypting the answer on its password, the client 21 sends an invocation request to user object 2 of user object 2's "login~pw(answer, challenge)" method which is received by object 2 at step 303. This method, which has two parameters (the answer to the challenge and the challenge itself) is used by a client 21 to signify to the key server that the client 21 knows the answer to the challenge and thus should be able to have access to the network. The "user" object 2 checks to see if the challenge has been correctly solved by the client 21 (step 304). If the challenge is correct, the user object 2 then returns (step 305) a user ticket which the client 21 stores locally. The client 21 will need this user ticket when it wishes to communicate with a specific server (e.g., file server 22) on the network (other than the server 23, which it must communicate with first to prove its identity to server 23).
When the client 21 wishes to communicate with file server 22 (e.g., to obtain a copy of a document stored at file server 22), the client 21 invokes "user" object 2's "use server(server, key)" method. This method, which has two parameters (the name of the server which the client 21 wants to communicate with, and the user ticket (or key) which the client 21 obtained at step 305. The "user" object 2 receives this invocation request at step 306. At step 307, the "user" object 2 then returns a server-specific ticket to client 21. The client 21 will then use this server-specific ticket when it communicates directly with file server 22 on line 213.
Should the file server 22 wish to communicate with another server in order to satisfy the request from client 21, the file server 22 must first send a request along line 212 to an ORB of server 23 to thus get an object reference to a "server" object 3 (an instance of the "server" subclass 3 of Fig. 1). Analogous steps are then carried out (to those described in Fig. 3) with respect to the file server 22 and the server 23 so that the file server 22 can authenticate itself.
Thus, classes 2 and 3 are sub-classes of the principal class 1 which can be accessed by the following methods (which each sub-class 2 and 3 inherits from principal class 1): login() -- > challenge This method is invoked in order to
request a challenge. The response is
the challenge.
loginpw(answer, challenge) -- > key This method is invoked in order to
provide the answer to the challenge
along with the challenge itself. The
response is a user ticket (or key), if the answer is determined to be
correct.
use~server(server, key) -- > key~server This method is invoked in order
to request to communicate with
a specific server. The request
must specify the identity of
the server along with the user
ticket (key) that was obtained
in response to the loginqw method. The response is a
server-specific key that is
used to communicate directly
with that server.
The "secure~base" class 1 also includes data which is encapsulated within each instance of the class (and which is also inherited by the sub-classes 2 and 3). This data includes the names, passwords and private keys of each machine (client or server) in the network.
In a second embodiment, the server 22 is an object-oriented server and is combined together with server 23. In this embodiment, as shown in
Fig. 4, client 41 wishes to have server 42 do some work. Client 41 must first prove its identity to the object-oriented Kerberos components resident on server 42 (steps of Fig. 3). In this embodiment, should client 41 wish to request another server (e.g., server 43) to do some work, client 41 must also prove its identity to this server 43 in a like manner (another user object 2 is instantiated within server 43 and the steps of Fig. 3 carried out again).
Claims (17)
1. An authentication server for use in a client/server computing network where a client processing device requests a working server processing device to perform a processing task, the authentication server comprising:
means for receiving an authentication request from a processing device;
means for processing the authentication request; and
means for informing the processing device of the result of said means for processing;
wherein said authentication server is embodied in object-oriented software.
2. The server of claim 1 wherein said means for processing instantiates an object representing said processing device.
3. The server of claim 2 wherein said means for processing includes means for processing invocation requests on methods of said object representing said processing device.
4. The server of claim 2 wherein said object is instantiated from a class which is a sub-class of a principal class holding methods and data for implementing authentication security techniques.
5. The server of claim 1 wherein said authentication server and said working server are integrated into the same processing device, and said means for receiving an authentication request receives a request from a client processing device.
6. The server of claim 1 wherein said authentication server and said working server are provided in separate processing devices.
7. The server of claim 1 wherein said means for receiving an authentication request instantiates an object representing a client processing device and instantiates an object representing a working server processing device.
8. In a client/server computing network where a client processing device requests a working server processing device to perform a processing task, a method of performing authentication of a processing device, the method comprising steps of:
receiving an authentication request from a processing device;
processing the authentication request; and
informing the processing device of the result of said processing;
wherein said processing step is carried out using object-oriented software.
9. The method of claim 8 wherein the receiving an authentication request step triggers the instantiation of an object representing said processing device.
10. The method of claim 9 wherein said processing step includes processing invocation requests on methods of said object representing said processing device.
11. The method of claim 9 wherein said object is instantiated from a class which is a sub-class of a principal class holding methods and data for implementing authentication security techniques.
12. The method of claim 8 wherein said receiving an authentication request step instantiates an object representing a client processing device and instantiates an object representing a working server processing device.
13. A computer program product stored on a computer readable storage medium in an authentication server for use in a client/server computing network where a client processing device requests a working server processing device to perform a processing task, the program product including software code portions for performing authentication of a processing device, the software code portions comprising:
means for receiving an authentication request from a processing device;
means for processing the authentication request; and
means for informing the processing device of the result of said processing;
wherein said computer program product is written in object-oriented form.
14. The computer program product of claim 13 wherein said means for processing instantiates an object representing said processing device.
15. The computer program product of claim 14 wherein said means for processing includes means for processing invocation requests on methods of said object representing said processing device.
16. The computer program product of claim 14 wherein said object is instantiated from a class which is a sub-class of a principal class holding methods and data for implementing authentication security techniques.
17. The computer program product of claim 13 wherein said means for receiving an authentication request instantiates an object representing a client processing device and instantiates an object representing a working server processing device.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9709532A GB2325314A (en) | 1997-05-12 | 1997-05-12 | Object-oriented system for authentication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9709532A GB2325314A (en) | 1997-05-12 | 1997-05-12 | Object-oriented system for authentication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| GB9709532D0 GB9709532D0 (en) | 1997-07-02 |
| GB2325314A true GB2325314A (en) | 1998-11-18 |
Family
ID=10812126
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| GB9709532A Withdrawn GB2325314A (en) | 1997-05-12 | 1997-05-12 | Object-oriented system for authentication |
Country Status (1)
| Country | Link |
|---|---|
| GB (1) | GB2325314A (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0398492A2 (en) * | 1989-05-15 | 1990-11-22 | International Business Machines Corporation | A flexible interface to authentication services in a distributed data processing system |
| EP0638860A2 (en) * | 1993-08-10 | 1995-02-15 | Addison M. Fischer | Method and apparatus for validating travelling object-oriented programs with digital signatures |
-
1997
- 1997-05-12 GB GB9709532A patent/GB2325314A/en not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0398492A2 (en) * | 1989-05-15 | 1990-11-22 | International Business Machines Corporation | A flexible interface to authentication services in a distributed data processing system |
| EP0638860A2 (en) * | 1993-08-10 | 1995-02-15 | Addison M. Fischer | Method and apparatus for validating travelling object-oriented programs with digital signatures |
Non-Patent Citations (3)
| Title |
|---|
| Byte, August 1986, p 195, pub McGraw-Hill * |
| Dialog record 01604333 of Software Magazine, v13, n9, June 1993, p102(3) * |
| Dialog record 02025876 of Software Magazine, v16, n11, Nov 1996, p71(6) * |
Also Published As
| Publication number | Publication date |
|---|---|
| GB9709532D0 (en) | 1997-07-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6282652B1 (en) | System for separately designating security requirements for methods invoked on a computer | |
| US5586260A (en) | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms | |
| EP0762289B1 (en) | Method and system for securely controlling access to system resources in a distributed system | |
| US5604490A (en) | Method and system for providing a user access to multiple secured subsystems | |
| US6134591A (en) | Network security and integration method and system | |
| US8132226B1 (en) | System, method and computer program product for an authentication management infrastructure | |
| EP1061432B1 (en) | Distributed authentication mechanisms for handling diverse authentication systems in an enterprise computer system | |
| US7281139B2 (en) | Authenticating legacy service via web technology | |
| US6243816B1 (en) | Single sign-on (SSO) mechanism personal key manager | |
| US6154741A (en) | Entitlement management and access control system | |
| US6226746B1 (en) | Stack-based system and method to combine security requirements of methods | |
| US5706349A (en) | Authenticating remote users in a distributed environment | |
| US6327658B1 (en) | Distributed object system and service supply method therein | |
| US20030005333A1 (en) | System and method for access control | |
| US6339827B1 (en) | Method for securing sensitive data in a LDAP directory service utilizing a client and/or server control | |
| JPH10240690A (en) | Client/server system, server and client terminals | |
| EP0540166B1 (en) | Secure object equivalency determination | |
| US7013388B2 (en) | Vault controller context manager and methods of operation for securely maintaining state information between successive browser connections in an electronic business system | |
| US5802276A (en) | Information handling system, method, and article of manufacture including a vault object for encapsulation of object security credentials | |
| Funfrocken | How to integrate mobile agents into web servers | |
| GB2325314A (en) | Object-oriented system for authentication | |
| JP2002505477A (en) | Stack-based security requirements | |
| US7606917B1 (en) | Method, apparatus and system for principle mapping within an application container | |
| Varadharajan et al. | Security model for distributed object framework and its applicability to CORBA | |
| Benantar et al. | Access control systems: From host-centric to network-centric computing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WAP | Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1) |