CA2016224C - A flexible interface to authentication services in a distributed data processing system - Google Patents
A flexible interface to authentication services in a distributed data processing systemInfo
- Publication number
- CA2016224C CA2016224C CA002016224A CA2016224A CA2016224C CA 2016224 C CA2016224 C CA 2016224C CA 002016224 A CA002016224 A CA 002016224A CA 2016224 A CA2016224 A CA 2016224A CA 2016224 C CA2016224 C CA 2016224C
- Authority
- CA
- Canada
- Prior art keywords
- authentication
- service
- machine
- requestor
- agent
- 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.)
- Expired - Fee Related
Links
- 238000012545 processing Methods 0.000 title claims abstract description 37
- 238000000034 method Methods 0.000 claims abstract description 53
- 230000008569 process Effects 0.000 claims abstract description 45
- 238000004891 communication Methods 0.000 claims description 18
- 230000006854 communication Effects 0.000 claims description 18
- 239000003795 chemical substances by application Substances 0.000 description 77
- 230000006870 function Effects 0.000 description 15
- 238000013461 design Methods 0.000 description 8
- 238000013475 authorization Methods 0.000 description 6
- 239000000284 extract Substances 0.000 description 5
- 230000006855 networking Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 3
- 150000001768 cations Chemical class 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000000717 retained effect Effects 0.000 description 3
- 230000002411 adverse Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/468—Specific access rights for resources, e.g. using capability register
-
- 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
Abstract
In a distributed data processing system, the authentication of a process at one node for the use of a service at another node is performed in a facility that is separate from the requestor and service process. The separate facility is also replaceable, thereby allowing different authentication policies to be implemented within the distributed data processing system. The requesting process and the service process merely pass the authentication information between themselves without attempting to interpret the work of the separate authentication facility. In addition to authenticating the requestor to the service, the service is also authenticated to the requestor.
Description
2 ~ 2 ~
A FLEXIBLE INTERFACE TO A~ N~l~IcATIoN SERVICES
IN A DISTRIBUTED DATA PROCESSING SYSTEM
Background of the Invention Field of the Invention This invention relates to a plurality of data processing systems connected by a communications link, and more particularly to the authentication of a process at one of the data processing systems for the use of a service at another one the data processing systems in a distributed networking environment.
.~,...
~$
' -2 ~
Description of the Related Art As shown in Fig. 1, a distributed networking environment 1 consists of two or more nodes A, B, C, connected through a communication link or a network 3.
The network 3 can be either a local area network (LAN), or a wide area network (WAN).
At any of the nodes A, B, C, there may be a processing system lOA, lOB, lOC, such as a workstation. Each of these processing systems lOA, lOB, lOC, may be a single user system or a multi-user system with the ability to use the network 3 to access files located at a remote node. For example, the processing system lOA at local node A, is able to access the files 5B, 5C at the remote nodes B, C, respectively.
Within this document, the term "server" will be used to indicate the processing system where the file is permanentl~ stored, and the term "client" will be used to mean any other processing system having processes accessing the file. It is to be understood, however, that the term "server" does not mean a dedicated server as that term is used in some local area network systems. The distributed services system in which the invention is implemented is truly a distributed system supporting a wide variety of applications running at different nodes in the system which may access files located anywhere in the system.
As mentioned, the invention to be described hereinafter is directed to a distributed data processing system in a communication network. In this environment, each processor at a node in the network potentially may ;. ~, -- ~: ~ -access all the files in the network no matter at which nodes the files may reside.
Other approaches to supporting a distributed data processing system are known. For example, IBM's Distributed Services for the AIX operating system is disclosed in US Patent No. 4,887,204 "A System and Method for Accessing Remote Files in a Distributed Networking Environment ", filed February 13, 1987 in .~-. .. .
~~-~ the name of Johnson et al. In addition, Sun .-i ~ :
Microsystems has released a Network File System (NFS) and Bell Laboratories has developed a Remote File System (RFS). The Sun Microsystems NFS has been described in a series of publications including S.R.
- ~ .
Kleiman, "Vnodes: An Architecture for Multiple File System Types in Sun UNIX", ~o~ference Procee~;ngs, US~lx 1986 Sl~mmer Te~hn,~l Co~fer~nce ~n~
h;hitio~, pp. 238 to 247; Russel Sandberg et al, "Design and Implementation of the Sun Network Filesystem~, ConferPnce Procee~1ngs, Usen;x 1985, pp. 119 to 130; Dan Walsh et al, "Overview of the Sun Network File System", pp. 117 to 124; JoMei Chang, "Status Monitor Provides Network Locking Service for NFS", JoMei Chang, ~SunNet~', pp. 71 to 75; and Bradley Taylor, "Secure Networking in the Sun Environment", pp. 28 to 36. The AT&T RFS has also been described in a series of publications including Andrew P. Rifkin et al, "RFS Architectural Overview", US~Ix ~nf~r~nce Procee~ 1ngs, Atlanta, Georgia (June 1986), pp. 1 to 12; Richard Hamilton et al, "An Administrator's View of Remote File Sharing", pp. 1 to 9; Tom Houghton et al, "File Systems Switch", pp. 1 to 2; and David J.
Olander et al, ~A Framework for Networking in System V", pp. 1 to 8.
One feature of the distributed services system in which the subject invention is implemented which distinguishes it from the Sun Microsystems NFS, for example, is that Sun's approach was to design what is essentially a stateless server. This means that the server does not store any information about client nodes, including such information as which client nodes have a server file open or whether client processes have a file open in read only or read_write modes. Such an implementatl~n simplifies the design of the server _ ' AT9-89-034 4 w."
- ' because the server does not have to deal with error recovery situations which may arise when a client fails " ~
or goes off-line without properly informing the server that it is releasing its claim on server resources.
An entirely different approach was taken in the - , ~
design of the distributed services system in which the present invention is implemented. More specifically, the distributed services system may be characterized as a "stateful implementation". A "stateful" server, such as that described here~ does keep information about who is using its files and how the files are being used. This requires that the server have some way to detect the loss of contact with a client so that accumulated state information about that client can be discarded. The cache management strategies described here cannot be implemented unless the server keeps such state information The problems encountered in accessing remote nodes can be better understood by first examining how a stand-alone system accesses files. In a stand alone system, such as 10 as shown in Fig. 2, a local buffer 12 in the operating system 11 is used to buffer the data transferred between the permanent storage 2, such as a hard file or a disk in a workstation, and the user address space 14. The local buffer 12 in the operating system ll is also referred to as a local cache or kernel buffer.
In the stand-alone system, the kernel buffer 12 is divided into blocks 15 which are identified by device number, and logical block number within the device. When a read system call 16 is iss~ted, ~t is issued with a file descriptor of the fi le ~ for A l)yte range within the file 5, as shown in step 101, Fig. l. The operating system 11 takes this inform~tion and converts it to device number, and logical block n~lmbers in ~he device, step 102, Fig.
A FLEXIBLE INTERFACE TO A~ N~l~IcATIoN SERVICES
IN A DISTRIBUTED DATA PROCESSING SYSTEM
Background of the Invention Field of the Invention This invention relates to a plurality of data processing systems connected by a communications link, and more particularly to the authentication of a process at one of the data processing systems for the use of a service at another one the data processing systems in a distributed networking environment.
.~,...
~$
' -2 ~
Description of the Related Art As shown in Fig. 1, a distributed networking environment 1 consists of two or more nodes A, B, C, connected through a communication link or a network 3.
The network 3 can be either a local area network (LAN), or a wide area network (WAN).
At any of the nodes A, B, C, there may be a processing system lOA, lOB, lOC, such as a workstation. Each of these processing systems lOA, lOB, lOC, may be a single user system or a multi-user system with the ability to use the network 3 to access files located at a remote node. For example, the processing system lOA at local node A, is able to access the files 5B, 5C at the remote nodes B, C, respectively.
Within this document, the term "server" will be used to indicate the processing system where the file is permanentl~ stored, and the term "client" will be used to mean any other processing system having processes accessing the file. It is to be understood, however, that the term "server" does not mean a dedicated server as that term is used in some local area network systems. The distributed services system in which the invention is implemented is truly a distributed system supporting a wide variety of applications running at different nodes in the system which may access files located anywhere in the system.
As mentioned, the invention to be described hereinafter is directed to a distributed data processing system in a communication network. In this environment, each processor at a node in the network potentially may ;. ~, -- ~: ~ -access all the files in the network no matter at which nodes the files may reside.
Other approaches to supporting a distributed data processing system are known. For example, IBM's Distributed Services for the AIX operating system is disclosed in US Patent No. 4,887,204 "A System and Method for Accessing Remote Files in a Distributed Networking Environment ", filed February 13, 1987 in .~-. .. .
~~-~ the name of Johnson et al. In addition, Sun .-i ~ :
Microsystems has released a Network File System (NFS) and Bell Laboratories has developed a Remote File System (RFS). The Sun Microsystems NFS has been described in a series of publications including S.R.
- ~ .
Kleiman, "Vnodes: An Architecture for Multiple File System Types in Sun UNIX", ~o~ference Procee~;ngs, US~lx 1986 Sl~mmer Te~hn,~l Co~fer~nce ~n~
h;hitio~, pp. 238 to 247; Russel Sandberg et al, "Design and Implementation of the Sun Network Filesystem~, ConferPnce Procee~1ngs, Usen;x 1985, pp. 119 to 130; Dan Walsh et al, "Overview of the Sun Network File System", pp. 117 to 124; JoMei Chang, "Status Monitor Provides Network Locking Service for NFS", JoMei Chang, ~SunNet~', pp. 71 to 75; and Bradley Taylor, "Secure Networking in the Sun Environment", pp. 28 to 36. The AT&T RFS has also been described in a series of publications including Andrew P. Rifkin et al, "RFS Architectural Overview", US~Ix ~nf~r~nce Procee~ 1ngs, Atlanta, Georgia (June 1986), pp. 1 to 12; Richard Hamilton et al, "An Administrator's View of Remote File Sharing", pp. 1 to 9; Tom Houghton et al, "File Systems Switch", pp. 1 to 2; and David J.
Olander et al, ~A Framework for Networking in System V", pp. 1 to 8.
One feature of the distributed services system in which the subject invention is implemented which distinguishes it from the Sun Microsystems NFS, for example, is that Sun's approach was to design what is essentially a stateless server. This means that the server does not store any information about client nodes, including such information as which client nodes have a server file open or whether client processes have a file open in read only or read_write modes. Such an implementatl~n simplifies the design of the server _ ' AT9-89-034 4 w."
- ' because the server does not have to deal with error recovery situations which may arise when a client fails " ~
or goes off-line without properly informing the server that it is releasing its claim on server resources.
An entirely different approach was taken in the - , ~
design of the distributed services system in which the present invention is implemented. More specifically, the distributed services system may be characterized as a "stateful implementation". A "stateful" server, such as that described here~ does keep information about who is using its files and how the files are being used. This requires that the server have some way to detect the loss of contact with a client so that accumulated state information about that client can be discarded. The cache management strategies described here cannot be implemented unless the server keeps such state information The problems encountered in accessing remote nodes can be better understood by first examining how a stand-alone system accesses files. In a stand alone system, such as 10 as shown in Fig. 2, a local buffer 12 in the operating system 11 is used to buffer the data transferred between the permanent storage 2, such as a hard file or a disk in a workstation, and the user address space 14. The local buffer 12 in the operating system ll is also referred to as a local cache or kernel buffer.
In the stand-alone system, the kernel buffer 12 is divided into blocks 15 which are identified by device number, and logical block number within the device. When a read system call 16 is iss~ted, ~t is issued with a file descriptor of the fi le ~ for A l)yte range within the file 5, as shown in step 101, Fig. l. The operating system 11 takes this inform~tion and converts it to device number, and logical block n~lmbers in ~he device, step 102, Fig.
3. I~ the block i~ in the c~:tle, step 103, the data is obtained directly ftom the cach~. step 105. In the case where the cache do~ t hold the sought for block at step 103, the data is J~d llltO the cache in step 104 before :: , :::
proceeding with st~ 105 where the data is obtained from the cache.
, .. -: '':
' ~' '~'.
~ AT9-89-034 5 : "
-~Any data read from the disk 2 is kept in the cache :: '~'::
~ ~block 15 until the cache block 15 is needed for some .~ .
~- ~other purpose. Consequently, any successive read requests from an application 4 that is running on the -processing system 10 for the same data previously read is accessed from the cache 12 and not the disk 2. Reading from the cache is far less time consuming than reading from the disk.
Similarly, data written from the application 4 is ~not saved immediately on the disk 2, but is written to '~ ~the cache 12. This saves disk accesses if another write :
-~operation is issued to the same block. Modified data : - , ~ -blocks in the cache 12 are saved on the disk 2 :, periodically.
Use of a cache in a stand-alone system that utilizes an AIX operating system improves the overall performance of the system since disk accessing is eliminated for successive reads and writes. Overall performance is enhanced because accessing permanent storage is slower and more expensive than accessing a cache.
In a distributed environment, as shown in Fig. 1, there are two ways the processing system lOC in local node C could read the file 5A from node A. In one way, the processing system lOC could copy the whole file 5A, and then read it as if it were a local file 5C residing at node C. Reading a file in this way creates a problem if another processing system lOA at another node A
modifies the file 5A after the file 5A has been copied at node C as file 5C. The processing system lOC would not have acce~s to these latest modifications to the file 5A.
Another way for ~roces~ing ~ystem lOC to access a file 5~ at node ~ is to re~d one block, e.g. Nl, at a .
time as the proce~sing Rystem ~t node C requires it. A
problem with this method i9 th~t every read has to go across the network comm~lnic~tion link 3 to the node A r where the file r~~ide~. ~ellding the data for every successive read i~ t ime cons~mlng, Accessing fil~~ across A network presents two competing problem~ ~s illustrated above. One problem involves the time r~ ired to transmit data across the network for succe~Rive reads and writes. On the other .
, , . ..
".~ _w5;
.'' . .
. ~, .....
_''; '1 a~ ' AT9-89-034 6 . ~" "~
.',"~,.!~ hand, if the file data is stored in the node to reduce ~i network traffic, the file integrity may be lost. For ~'~ 1 example, if one of the several nodes is also writing to -~ the file, the other nodes accessing the file may not be :-- :: -:
accessing the latest updated data that has just been written. As such, the file integrity is lost since a node may be accessing incorrect and outdated files.
In a stand-alone data processing system, file access control is often provided in order to protect sensitive information that users do not want to share with each other. A problem confronted with distributed data processing systems is how to distribute this same model of control and provide secure access to a user s . ~ ~
information remotely while keeping other remote users from inadvertently or maliciously accessing or manipulating data belonging to another user.
Two problems that must be solved in order to provide a secure remote access for users are authentication and authorization. Authentication is the process of identifying a user of a data processing system. Users typically accomplish authentication by presenting the user's name, or account number for the system, followed by a secret password which should only be known by that user. Presenting the secret password, which can be validated by the system, allows the system to authenticate the user to be who the user claims to be.
Once authenticated, the system may then authorize this user to have access to resources managed by the data processing system. Therefore, authentication is the identification of a user, and authorization is the granting of a privilege to a user to gain some kind of access to the system.
As mentioned above, authent1cation of local users is often accomplished through th~ ~Ise of a shared secret.
This secret is typically a pasnword which the user enters at a prompt. The ~ystem then compares this password to a recorded version of the r~sword. If the system determines that tll~ password 1s correct, the user is authenticated. Remnte authentication is more difficult than that previou~l/ described.
~
~i .
''-' ~A procedure for remote authentication is '--described in the following papers. ~Kerberos: An Authentication Service For Open Network Systems", Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I.; pages 1-15, USENIX, Dallas, TX, Winter, 1988. "Project Athena Technical Plan, Section E.2.1, ~Kerberos Authentication and Authorization System", --~Miller, S.P.; Neuman, B.C.; Schiller, J.I.; Saltzer, J.H.; pages 1-36, Massachusetts Institute of Technology, October 27, 1988. This Kerberos based remote authentication authenticates users working at ,, one node in a distributed data processing system to services running on the same node or other nodes in the distributed system. A distinctive property of the Kerberos protocol is that users can be authenticated with services running on nodes which share no secret with the user. If a simple password based authentication scheme were used, each user would have to share a secret with each machine in the entire distributed system. By using the Kerberos protocol, users need to share a secret with only one machine;
the machine running the Kerberos authentication , service.
- Kerberos authentication works as follows. In ~~ .
~ order to be authenticated to a remote service, the : ~ , user must present a specially constructed data structure, called a ticket, to the service that the user wishes to be authenticated to. This ticket is particular to the user and the service. That is, each service requires that these tickets are tickets intended for that service. Moreover, these tickets are specially constructed for an individual user who wants to be authenticated. These tickets are issued by the par'_ of the Kerberos authentication server called the ticket granting service. Before using the service, say a remote print server, a user acquires a ticket for that print server. The user requests the Kerberos ticket granting service to issue a ticket for that user for the use of the print server. The Kerberos ticket granting service constructs the ticket, gives it to the user, and the user presents it to the print server. The print server examines the ticket ~, ,"" ,,",~
~ ~ .
~- AT9-89-034 8 and can determine that the sender was indeed the claimed user.
' !In detail, this Kerberos scheme is more complex in ' ~-order to ensure that tickets can not be forged or stolen ~-by another user. In addition, the messages for passing tickets between machines are designed such that the ::: , messages can not be recorded and replayed. The Kerberos scheme also ensures that the the user can not trick the ticket granting service itself. This last step can be accomplished by requiring a ticket to use the ticket granting service. This master ticket is acquired by users before any other ticket can be issued for that user. Once a user has a master ticket, the user can present the master ticket to the ticket granting service and be issued tickets for other services in the distributed system.
Another distinctive feature of the Kerberos authentication scheme is that while the user must go to the authentication server to request tickets, the service to which these tickets are being presented does not need to communicate with the Kerberos authentication service during the user authentication.
The Kerberos protocol provides a sophisticated authentication scheme. However, such schemes are not appropriate for small networks where the overhead in administe.ing a Kerberos server may not justify its use.
......
~ In such cases, other authentication schemes are possible which may just simply involve the sharing of a secret between every user and every node in the distributed system. If the distributed system has only a few machines, such as three or so, it may be easier for each user to maintain a password on each machine and to authellticate that password periodically to ensure that the users are not compromised.
A thlrd pos~ible authe~ ation scheme might be appropriate for networkA that ~r~t larger than those that - can be conveniently managed by users needing individual ipasswords on each machins y~t- are smaller than would ustify a Kerbero~ authenticatlon protocol. This third scheme might use ~ centraliz~d authentication server which all of the n~de8 communlcate with. A password . . .
'''''' : ~ ' might be presented to a remote service by a user, and the remote service checks with the central authentication server to determine whether the password is correct.
This requires services to communicate with the authentication server instead of users. This is in contrast to the Kerberos scheme where services do not need to communicate with the authentication server during user authentication.
As illustrated above, there is a wide range of possible implementations of authentication servers that , ~ .
may be appropriate for distributed systems providing user authentication.
An operating system, such as the AIX operating system, which provides for distributed functions such as in Distributed Services of the AIX operating system, uses remote authentication to authenticate client machines to servers, servers to client machines, and users to server machines. However, it may be desirable to run an operating system having distributed functions in various sizes of networks having a range of nodes from one or two nodes to hundreds or thousands of nodes. Consequently, an operating system providing distributed functions must run in the presence of various authentication schemes from the simplest most straight forward scheme to the most complex and sophisticated scheme.
An efficient way of implementing a distributed services function of an operat~ng system is to modify the operating system k~rnel to support distributed service operations. This inc31ldes the communication between nodes and the m~ln gement an~l synchronization of the facilities being distributed. When a user operation on one machine caus~ ~ request to be sent to a remote machine, that usel ~u~t be authenticated to the remote machine. This acti~ity causes programs to be executed at the remote machine T1~e distributed service function of the operating syst~m must perform the authentication of the remote user, but to do ~o, it must use the network's authentication scheme, for which various schemes are possible and can operate very differently from one another. Additionally, this authentication may require communications with the remote authentication server at L
' AT9-89-034 10 ~.
either the user side or at the remote machine side.
Since it is impossible to anticipate all possible authentication schemes that the network may be using, it is desirable for a distributed service function of the operating system to have a flexible authentication protocol that allows it to use whatever available authentication scheme is running on the network.
For example, a distributed service of the operating :.: .
system gets to a remote machine with a request from a user, but the remote machine may discover that it has never seen this user before. The remote machine then may require the user to authenticate itself to the remote machine. However, the distributed service function may not know how the authentication is to be performed. If the distributed service function determined how the authentication process is to be performed, this would limit the users of the distributed service function of an operatiny system to the one predetermined authentication scheme. Furthermore, if the predetermined authentication scheme requires remote communications with the server, there is a variety of exceptions and failures which are difficult to provide for inside the kernel of the operating system at the point where the authentication process would need to be performed. If the communica tions to the authentication server breaks, and the authentication process is in~ide the kernel, all proce~sing within the data pr~ sing system may come to a halt while the o~erating ~yRt~m kernel is waiting while trying to communicate with the remote authentication server.
Summary of the In~ tion It is there~ le an object of this invention to provide a mechanis~ whlch is general enough to interface to any of the prev1~usly known authentication schemes.
The system and method of this invention defines an interface between an operating system providing distributed service functions and a user program providing an authentication scheme. This interface is well defined and highly structured such that the kernel of the operating system does not change at all depending ,:
.~;
":~
: f-~ AT9-89-034 ll ~ ~.
upon the authentication services in the network that are ~ being utilized. A program providing an authentication - scheme can be interchangeable with other authentication , ,. "~
programs whenever the authentication scheme changes in -- the network. In addition, utilizing a user program at the remote machine to perform the authentication allows the user program to be killed, restarted, and scheduled as a regular program without affecting the performance of the underlying operating system. The complexity of authentication lies in the program and not in the kernel of the operating system.
An authentication daemon program is used at both the user initiating node and the receiving service node. A
set of message flows allows a distributed service ' function within the operating system to use the results of these authentication daemons in a way that is transparent to the distributed services function. The - ~ distributed services function merely passes the informat~on back and forth without attempting to interpret the work of the authentication daemon.
Accordingly, different authentication daemon programs using different authentication schemes can be used interchangeably within the network without affecting or changing the underlying distributed service function of the operating system. Likewise, the same distributed service function can be used within various networks having different autllentic~tion schemes in the ; authentication daemon t1r.~l in ~h network.
More specifically, A 1~uest sent to a remote service that reqt1ires autllentlcation includes an object ~ called the auth~ntic~tion information object. This -~~~ authentication inf~rmAtion .-~bject and an associated ::, authentication acknowledqement value are constructed, at c~ the requestor s n~ , by the authentication daemon from information about ~h~ requestor. The contents of these authentication ite~ and the means for their construction are preferably unknown outside of the authentication daemon itself. Th~ a~t;11enticatlon acknowledgement value is retained and the Authel1tication information object is included in the message used for the request. The service, before performing the request, extracts the - ~ , .
E
~ ,, ..~"~
t~r-' AT9-89-034 12 ~r ,' ?~ ' ' S
" ~ "
authentication information object from the request and pas~es it to a second authentication daemon running at the service's node. This second authentication daemon '"7~ ~ uses the authentication information object to authenticate the requestor according to the authentication policy supported by the daemons. The second authenti ~ cation daemon also returns a second authentication -~ acknowledgement value that is returned to the requestor in the reply to the request. This second authentication - acknowledgement is compared with the first authentication acknowledgement previously retained by the requestor to f ensure that the identity of the remote service is that of the intended service.
Brief DescriPtion of the Drawing '~ ~ Fig. 1 is a block diagram of a distributed data processing system known in the art.
Fig. 2 is a block diagram showing a stand-alone data processing system known in the art for accessing a file through system calls.
Fig. 3 is a flow diagram of the data processing - system of Fig. 2 accessing a file through a system call.
Fig. 4A is a request_for_service message which is used by a process running on a client machine in order to request that a remote service be performed.
Fig. 4B illustrates the messages that flow between the authentication agent and the requestor and between the authentication agent and tlle service.
Fig. 5 shows ~ client dAtA processing system and a server data proces~ g 8y8t ~m in a distributed data processing system h~ving a sepArate authentication agent for performing autll~ntication Fig. 6 is A flow show~ng the operations of the requestor, the aut~entication ~gent, and the service in the method of thi.~ i-lvention.
Description of the ~referred Embodiment With reference to Figure 4A, the internode message request_for_service 410 used herein is described. The request_for_service message 410 is used by a process running on a client machine in order to request that a - ':
.
' .~, ,, ,~
~~ - AT9-89-034 13 ~ 2 ~ ~:
remote service be performed. The request 411 has an opcode 413 indicating the specific operation requested.
The request 411 also has an operation field 420 used to indicate the desired operation to be performed by the server. The authentication info field 416 in the request i8 used to pass enough information to the remote machine to authenticate the process performing the request. The remote machine responds with the reply 412. The opcode field 414 indicates that this is the reply for the particular kind of request. The return code (rc) 417 in the reply is used to indicate the success or failure of the remote machines attempt to execute the request. An acknowledgement is returned in the ack field 419. The ack is used to verify that correct identification between the requesting process and the remote machine has occurred.
Fig. 4B shows the messages that flow between the authentication agent and the requestor and between the authentication agent and the service. The requestor to :
authentication agent message 520 contains information describing the requestor 531 and information describing the service 532 that the request will be sent to. The authentication agent to requestor message 521 contains an authentication information object 416 and an authentication acknowledgement value 534. The service to authentication agent message 523 contains only the authentication info object 416. The authentication agent to service message 524 contains Another authentication acknowledgement value 419 and a ~et of credentials 536 that are used by the servl~e to authenticate the requestor.
Referring to Fig. 5, a machine 503 contains a -:
~- requestor 504 that mAkes use of an authentication agent 502 through messaq~s 520, 521 The authentication agent - 502 refers to data ~tored on ~1sk 501. A second machine ~ 513 contains a "~vice 514 that makes use of an -~ authentication a~ 12 through messages 523, 524. The requestor 504 commllnic~tes with the service 514 via the request_for_service Leqllest 411 and its reply 412.
In the preferred ~mbodiment, a first machine 503 is communicating with ~ second machine 513 over a network.
, " ~ ", =,"~,""~
~ ~ AT9-89-034 14 - j. ~~ ~
-~ Rather than performing the authentication operation within the requestor process 504 and the service process ~ 514, which may be running in an operating system of the -~ ~ machines, the authentication operation is performed in - ~ the authentication agent programs 502, 512 at both of the - / nodes. These authentication agents may be user level - programs as used in systems running any type of operating system or daemons as used in systems executing the AIX
- operating system or other operating systems based on the UNIX operating system.
; '~ '7'''~ The following description refers to Fig. 4A, Fig.
- 4B, Fig. 5, and Fig. 6, concurrently. Before a process at a first machine begins to send a request 411, step 601, to use the services of a second machine, an authentication procedure must first be performed. The ~ requesting process 504 sends a message 520 to the first - ~ authentication agent 502 at the first node in order to initiate authentication, step 602. This message contains information 531 describing the process making the request :- .
and information 532 identifying the requested service.
The first authentication agent 502 uses the contents of the m~s~age 520 to construct a reply 521, step 603, returned to the requesting process, step 604. This reply 521 contains authentication information 416 and an authentication ack 534. The way in which the authentication agent uses the contents of message 520 depends upon the particular authentication policy being supported; but the way that the requesting process uses the reply 521 is independent of the policy supported by the authentication agent. The requesting process does not interpret either the auth~n~ication information 416 or the authentication ACk 534 The only operations that the requesting proces6 needs to perform with these elements are the transmi~sion of the authentication information to th~ remote service in a request, steps 605, 606 and a bitwise compari~on for equality between the authentication ~ck 534 received and retained, step 606, from the loc~; authentication agent 502, and the authentication ack ~19 ln reply 412 received from the remote service.
.-'.~,, ,~ . , ~
~ AT9-89-034 15 :~ .
In addition, the service receiving the request 411 does not need to interpret the information contained in the authentication information field 416. The service, like the requestor, treats the authentication information in the same manner independent of the authentication policy that it supports. The service always passes the authentication information to the authentication agent 512, step 607, where interpretation of this information is performed, step 608. The agent will find different contents in the authentication information message 523 depending upon the particular authentication policy being supported by the authentication agents 502 and 512. In the message 524 sent from the agent 512 to the service 514, step 609, the agent places a set of credentials 536 that describe the remote requestor in a manner that is meaningful to the service. Additionally, the agent places an authentication ack 419 in this message that does not need to be interpreted by the service. Like the authentication information, the authentication ack 419 is treated in the same manner by the service for all authentication policies supported by the authentication agents. The only operation that the service performs on the authen~ication ack 419 is returning it to the requestor in reply 412. The service makes a determination, step 610, based on the credentials 536 on .--- . .
;~ the authentication and authorization of the requestor'q ~:: r permission to request an operation 420 of the service, conditionally performing the requested operation, step 611. The results of this determination and operation are returned in a return code 417 to the requestor in a reply message 412 along with the authentication ack 419, step 612.
The requestor rece~ves t h~ reply 412 and extracts the authentication ack 419 And compares it to the authentication ack ~34 previou~ly received from the local authentication ag~lt 502, ste~ 613. If the two acks are bitwise equal, th~ requestor Is assured of the remote service s identity to the limit of the ability of the authentication pr~'o~ol supported by the agents. Upon verifying the identlty of the service, the requestor .. ~,~ , ~~ ~ examines the return code 417 to determine the outcome of ~;-.-.,/
.
2 ~' the original request, step 614, completing the request ~: . for service, step 615.
:~: The following programming design language code illustrates the processing at the authentication agent.
/* authentication agent */
LOOP FOREVER
:~ await message;
IF request is a requestor to agent message THEN
use requestor information found in message along with the service information . found in the message to construct both authentication information and an authentication acknowledgement;
send message reply containing authentication information and authentication ack back to requestor;
ELSE /* request is a service to agent message */
use the authentication info to construct a set of credentials and an authentication ack;
send message reply containing the set of credentials and the authentication ack back to service;
ENDIF;
ENDLOOP;
Copyright IBM Corporations 1989 The following programming design language code illustrates the processing at th~ requestor.
/* requestor */
/* about to make ~ request of a remote service */
construct a messaq~ containin~t A description of the process makin~J the request and a description of the remote sel:lce:
send this message ~ lthentication agent;
await reply from all~helltication agent; ~' .
,..
AT9-89-034 17 ~ 4 . ~
save the authentication ack returned in reply from agent;
construct a request for remote service, include authentication information returned in reply from the authentication agent;
~ send request to remote service;
:~ await reply from the service;
IF authentication ack in reply from service ~~~. = saved authentication ack THEN
:~ -: /* remote service authenticated */
~ ~ examine the result of the remote operation;
:-;1 ELSE
, ~, t /* remote service not authenticated */
/* ignore the returned return code */
~-~ ENDIF;
Copyright IBM Corporation 1989 ~ The following programming design language code ,': illustrates the processing at the service.
/* service */
LOOP FOREVER;
await request from a remote requestor;
extract the authentication information from the request;
send authentication information to the authentication agent;
await reply from agent;
extract credentials for remote requestor from the reply;
extract authentication ack from the reply and save it;
: rF credentials indicate that the requestor has permission to have th~ ~erver perform the operation requested ill the request from the requestor THEN
perform th~ operation:
; return co~le := the te~ults of the operation;
ELSE
., return c~ value indicating permission ., '',f ' failure;
- ENDIF;
construct a reply containing the return code and the saved authentication ack;
; - ~send reply back to the server;
ENDLOOP;
-~ Copyright IBM Corporation 1989 . . ~. .
Note, that the design suggested above employs -~ messages to communicate between the service and the 'A . ,:
authentication agent and between the requestor and the authentication agent. These messages are shown in Fig. 4B. This choice of communication interface is intended to allow multiple processes, either requestors or services or combinations of the two, running on the same node to use a single agent. In the preferred embodiment using the AIX operating system the interprocess communication facilities called message queues provide this type of interface.
These message queue facilities are described in the "AIX Operating System Technical Reference", second edition, September, 1986, order number SV21-8009, part number 74X9990, and more specifically pages 2-71 to 2-85. This allows multiple processes to share the authenti cation daemon process. By using a well defined interface based on messages, the preferred embodiment allows the daemon process to be replaced without necessitating any changes in its clients, i.e., the requestors and the services.
For example, if Kerberos based authentication is being performed, the agent will acquire a Kerberos ticket for the requestor to use the remote service.
This may involve searching id to name tables stored in the password file on disk 501 or ticket caches stored on disk 501 or memory. It may further involve communication with a remote Kerberos server using the Kerberos protocols. If Kerberos is used, the authentication info 416 contains all of the information that is needed by a service to authenticate a remote requestor using Kerberos.
~ .
To illustrate how the preferred embodiment can be , ~
~ ~used to support the kerberos protocol, the steps performed by the authentication agent are further ~; described. Message 520 to the authentication agent is ~ used by the agent to determine the requesting process s --~- associated user id. In the preferred embodiment, this id is contained in the field 531 describing the requestor - and is a small integer used to identify the user on whose behalf the request is running. The authentication agent uses this id to locate the Kerberos tickets owned by this user. In the preferred embodiment, the agent will find these tickets in a file located on the disk 501 under the name /tmp/tkt(uid) where (uid) is the actual user id. In this file, a ticket for the requested service described by field 532 may be found. If such a ticket is not found, a new ticket for the requested service is acquired by the agent. The agent acquires a new ticket by sending a ticket request to the Kerberos ticket granting service.
This ticket request is constructed according to the requirements of the Kerberos protocol as described in "Kerberos Authentication and Authorization System", - Miller, S.P. et al. Basically, the agent constructs an encrypted authenticator containing a timestamp and sends it, along with a ticket for use of the ticket granting service, to the ticket granting service in its requests for a ticket to the desired service.
In response to the ticket request, the authenti cation agent will receive from the ticket granting service ~ -cicket for the desired service and a session key for use with this service. The agent will also construct an authenticator encrypted with the session key an combine this with the ticket just received. The agent places this in the authentication info field 416 of the reply 521 that is returned to the requestor.
Additionally, the agent will construct an authentication ack from the value of the timestamp placed in the encrypted authenticator. It doe~ this by adding one to - the timestamp and encrypting it with the session key.
;, This authentication ACk i8 pl ~ced in field 534 of the reply.
The requestor, upon rec~lving the reply 521, does not need to be AW~t e thAt th~ authentication field and -: the authentication ,tck are cor-~tructed in order to take :
:
2 ~
advantage of the Kerberos authentication protocols.
Instead, the requestor treats these as abstract values, handling them in the same way independent of the way in which the authentication agents are performing authentication. The authentication info field is sent to the remote service in message 411 where it is passed in message 523 to the authentication agent running at the remote node. The remote authentication agent obtains, from the ticket, verification of the remote requestor s identity and the session key that will be used with thi~
remote requestor. This information is encrypted in the ticket in a manner which makes tickets unforgable.
Additionally, the remote agent checks the authenticator sent with the ticket, decrypting it with the session key, to find the timestamp. The timestamp is examined to make sure that this request is not a replay of a previous request. The timestamp is also used to construct an authentication ack in the same manner as was done by the first authentication agent. The authentication ack ib returned to the service in field 419 along with a description of the requestor s identity in field 536 of message 524. The ack constructed at the service authentication agent is then returned in message 412 to the requestor where it is compared to the authentication ack constructed at the requestor s node. This completes a Kerberos based authentication scheme using the preferred embodiment.
While performing the above described request, the agent communicates with the Kerberos ticket granting service. This may be running on a remote node and hence require network communication. This is not a problem for the agent since it is a regular scheduled process which can be put to sleep while awaiting a reply from the Kerberos ticket granting service without adversely impacting the performance of other processes on the system where the agent is runnin~. If the requestor had attempted to acquire the tick~ directly without going through an authenticatioll agent, the requestor might have to sleep awaiting an I/0 request. This could impact system performance ~versely if the requestor was running under kernel st~te in ~ome operating systems.
'~
~ .
Furthermore, some operating systems cannot initiate I/0 such as this while in the middle of processing a previous I/0 request for a process. This can occur if a process attempts to perform I/0 on a remote file. While in the middle of an I/0 request for a remote file, it may be discovered that authentication operations need to be performed that involve I/0 such as communicating with the Kerberos ticket granting service, causing problems in systems where a separate authentication agent is not used. In this preferred embodiment, authentication operations can be performed by the separate agent while a requesting process is in a state where it would not be able to perform the I/0 necessary for the authentication at that time.
Likewise, a different authentication policy can be used in conjunction with this preferred embodiment. When the authentication agent receives message 520 it obtains the user id from field 531. It should be noted that in the preferred embodiment all information that might be used by an authentication policy is passed in field 531 so that different implementations of a policy or different policies running in the agent will find all information needed in this field. The user id is used to search the password file on disk 501 for a password that this user has prearranged to use with the remote service identified by field 532. This password and an associated reply password are obtained by this lookup operation.
The password is placed in field 416, the authentication info fiel~l, and the reply password is placed in field 534, the authentication ack field, of the message 521.
The requestor sends the authentication info field 416 to the service where it is passed to the remote a~ent in message 523. The remote agent uses the password to search a file stored on disk 511 to locate a description of the identity of the requestor. If found, this identity information is placed in field 536 along with a reply password found in the same ~ile and placed in field 419, the authentication ~ick fi~ld of message 524. The service returns the a~it}lentlc~ition ack value to the reque~tor where it, the reply password found at the service node, is c~mpa~ed with the authentication ack .-~ ~ .
~- AT9-89-034 22 . ~
, ~, obtained from the requestor authentication agent, the reply password found in the local file. If they are the same, successful mutual authentication has occurred.
Another possible authentication policy might be implemented with a centralized authentication system.
Like the scheme just described, the authentication info field is a password passed from the requestor to the service and checked in the service authentication agent.
The authentication ack is a reply password passed to the requestor from both the requestor authentication agent and the service, which obtains it from the servlce authentication agent. Instead of finding these passwords in files on disks 501, 511, these passwords are obtained from a centralized authentication system by the agent.
Finally, the agents may be in direct communication with each other. This allows authentication policies that work outside of the network used for request for service operations to be supported. For example, a physically secured communication channel between the a~ents could be used to dynamically determine appropriate authentication info values and authentication ack values.
Requestors and services can communicate over lower cost or more available communication channels while achieving secure authentication through the use of the preferred embodiment where the agents communicate over a single secure channel.
It should be noted that the process acting as the authentication agent ln a node can act in both roles, as the requestor authentication agent and the service authenticat1on agent because both services and requestors may be running in the same machine.
Simply by disconnecting the authentication daemons, and replacing them with another authentication daemon program, the network can perform authentication using any authentication scheme. For example, the authentication daemon could perform either a centralized authentication scheme or a Kerberos authentication scheme.
Alternatively, the authelltication daemon may simply just examine a file containing passw~-l(ls.
As shown above, th~ autll~ntication of remote users by servers can be rerformed in various ways. Under some 'AT9-89-034 23 circumstances, there is very little reason to be suspicious of requests arriving at a server and low cost authentication of remote users is justified. In other environments, servers must exercise greater vigilance.
No one policy will be best for all cases. Therefore, this invention supports a range of authentication and authorization policies.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of the invention.
~,
proceeding with st~ 105 where the data is obtained from the cache.
, .. -: '':
' ~' '~'.
~ AT9-89-034 5 : "
-~Any data read from the disk 2 is kept in the cache :: '~'::
~ ~block 15 until the cache block 15 is needed for some .~ .
~- ~other purpose. Consequently, any successive read requests from an application 4 that is running on the -processing system 10 for the same data previously read is accessed from the cache 12 and not the disk 2. Reading from the cache is far less time consuming than reading from the disk.
Similarly, data written from the application 4 is ~not saved immediately on the disk 2, but is written to '~ ~the cache 12. This saves disk accesses if another write :
-~operation is issued to the same block. Modified data : - , ~ -blocks in the cache 12 are saved on the disk 2 :, periodically.
Use of a cache in a stand-alone system that utilizes an AIX operating system improves the overall performance of the system since disk accessing is eliminated for successive reads and writes. Overall performance is enhanced because accessing permanent storage is slower and more expensive than accessing a cache.
In a distributed environment, as shown in Fig. 1, there are two ways the processing system lOC in local node C could read the file 5A from node A. In one way, the processing system lOC could copy the whole file 5A, and then read it as if it were a local file 5C residing at node C. Reading a file in this way creates a problem if another processing system lOA at another node A
modifies the file 5A after the file 5A has been copied at node C as file 5C. The processing system lOC would not have acce~s to these latest modifications to the file 5A.
Another way for ~roces~ing ~ystem lOC to access a file 5~ at node ~ is to re~d one block, e.g. Nl, at a .
time as the proce~sing Rystem ~t node C requires it. A
problem with this method i9 th~t every read has to go across the network comm~lnic~tion link 3 to the node A r where the file r~~ide~. ~ellding the data for every successive read i~ t ime cons~mlng, Accessing fil~~ across A network presents two competing problem~ ~s illustrated above. One problem involves the time r~ ired to transmit data across the network for succe~Rive reads and writes. On the other .
, , . ..
".~ _w5;
.'' . .
. ~, .....
_''; '1 a~ ' AT9-89-034 6 . ~" "~
.',"~,.!~ hand, if the file data is stored in the node to reduce ~i network traffic, the file integrity may be lost. For ~'~ 1 example, if one of the several nodes is also writing to -~ the file, the other nodes accessing the file may not be :-- :: -:
accessing the latest updated data that has just been written. As such, the file integrity is lost since a node may be accessing incorrect and outdated files.
In a stand-alone data processing system, file access control is often provided in order to protect sensitive information that users do not want to share with each other. A problem confronted with distributed data processing systems is how to distribute this same model of control and provide secure access to a user s . ~ ~
information remotely while keeping other remote users from inadvertently or maliciously accessing or manipulating data belonging to another user.
Two problems that must be solved in order to provide a secure remote access for users are authentication and authorization. Authentication is the process of identifying a user of a data processing system. Users typically accomplish authentication by presenting the user's name, or account number for the system, followed by a secret password which should only be known by that user. Presenting the secret password, which can be validated by the system, allows the system to authenticate the user to be who the user claims to be.
Once authenticated, the system may then authorize this user to have access to resources managed by the data processing system. Therefore, authentication is the identification of a user, and authorization is the granting of a privilege to a user to gain some kind of access to the system.
As mentioned above, authent1cation of local users is often accomplished through th~ ~Ise of a shared secret.
This secret is typically a pasnword which the user enters at a prompt. The ~ystem then compares this password to a recorded version of the r~sword. If the system determines that tll~ password 1s correct, the user is authenticated. Remnte authentication is more difficult than that previou~l/ described.
~
~i .
''-' ~A procedure for remote authentication is '--described in the following papers. ~Kerberos: An Authentication Service For Open Network Systems", Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I.; pages 1-15, USENIX, Dallas, TX, Winter, 1988. "Project Athena Technical Plan, Section E.2.1, ~Kerberos Authentication and Authorization System", --~Miller, S.P.; Neuman, B.C.; Schiller, J.I.; Saltzer, J.H.; pages 1-36, Massachusetts Institute of Technology, October 27, 1988. This Kerberos based remote authentication authenticates users working at ,, one node in a distributed data processing system to services running on the same node or other nodes in the distributed system. A distinctive property of the Kerberos protocol is that users can be authenticated with services running on nodes which share no secret with the user. If a simple password based authentication scheme were used, each user would have to share a secret with each machine in the entire distributed system. By using the Kerberos protocol, users need to share a secret with only one machine;
the machine running the Kerberos authentication , service.
- Kerberos authentication works as follows. In ~~ .
~ order to be authenticated to a remote service, the : ~ , user must present a specially constructed data structure, called a ticket, to the service that the user wishes to be authenticated to. This ticket is particular to the user and the service. That is, each service requires that these tickets are tickets intended for that service. Moreover, these tickets are specially constructed for an individual user who wants to be authenticated. These tickets are issued by the par'_ of the Kerberos authentication server called the ticket granting service. Before using the service, say a remote print server, a user acquires a ticket for that print server. The user requests the Kerberos ticket granting service to issue a ticket for that user for the use of the print server. The Kerberos ticket granting service constructs the ticket, gives it to the user, and the user presents it to the print server. The print server examines the ticket ~, ,"" ,,",~
~ ~ .
~- AT9-89-034 8 and can determine that the sender was indeed the claimed user.
' !In detail, this Kerberos scheme is more complex in ' ~-order to ensure that tickets can not be forged or stolen ~-by another user. In addition, the messages for passing tickets between machines are designed such that the ::: , messages can not be recorded and replayed. The Kerberos scheme also ensures that the the user can not trick the ticket granting service itself. This last step can be accomplished by requiring a ticket to use the ticket granting service. This master ticket is acquired by users before any other ticket can be issued for that user. Once a user has a master ticket, the user can present the master ticket to the ticket granting service and be issued tickets for other services in the distributed system.
Another distinctive feature of the Kerberos authentication scheme is that while the user must go to the authentication server to request tickets, the service to which these tickets are being presented does not need to communicate with the Kerberos authentication service during the user authentication.
The Kerberos protocol provides a sophisticated authentication scheme. However, such schemes are not appropriate for small networks where the overhead in administe.ing a Kerberos server may not justify its use.
......
~ In such cases, other authentication schemes are possible which may just simply involve the sharing of a secret between every user and every node in the distributed system. If the distributed system has only a few machines, such as three or so, it may be easier for each user to maintain a password on each machine and to authellticate that password periodically to ensure that the users are not compromised.
A thlrd pos~ible authe~ ation scheme might be appropriate for networkA that ~r~t larger than those that - can be conveniently managed by users needing individual ipasswords on each machins y~t- are smaller than would ustify a Kerbero~ authenticatlon protocol. This third scheme might use ~ centraliz~d authentication server which all of the n~de8 communlcate with. A password . . .
'''''' : ~ ' might be presented to a remote service by a user, and the remote service checks with the central authentication server to determine whether the password is correct.
This requires services to communicate with the authentication server instead of users. This is in contrast to the Kerberos scheme where services do not need to communicate with the authentication server during user authentication.
As illustrated above, there is a wide range of possible implementations of authentication servers that , ~ .
may be appropriate for distributed systems providing user authentication.
An operating system, such as the AIX operating system, which provides for distributed functions such as in Distributed Services of the AIX operating system, uses remote authentication to authenticate client machines to servers, servers to client machines, and users to server machines. However, it may be desirable to run an operating system having distributed functions in various sizes of networks having a range of nodes from one or two nodes to hundreds or thousands of nodes. Consequently, an operating system providing distributed functions must run in the presence of various authentication schemes from the simplest most straight forward scheme to the most complex and sophisticated scheme.
An efficient way of implementing a distributed services function of an operat~ng system is to modify the operating system k~rnel to support distributed service operations. This inc31ldes the communication between nodes and the m~ln gement an~l synchronization of the facilities being distributed. When a user operation on one machine caus~ ~ request to be sent to a remote machine, that usel ~u~t be authenticated to the remote machine. This acti~ity causes programs to be executed at the remote machine T1~e distributed service function of the operating syst~m must perform the authentication of the remote user, but to do ~o, it must use the network's authentication scheme, for which various schemes are possible and can operate very differently from one another. Additionally, this authentication may require communications with the remote authentication server at L
' AT9-89-034 10 ~.
either the user side or at the remote machine side.
Since it is impossible to anticipate all possible authentication schemes that the network may be using, it is desirable for a distributed service function of the operating system to have a flexible authentication protocol that allows it to use whatever available authentication scheme is running on the network.
For example, a distributed service of the operating :.: .
system gets to a remote machine with a request from a user, but the remote machine may discover that it has never seen this user before. The remote machine then may require the user to authenticate itself to the remote machine. However, the distributed service function may not know how the authentication is to be performed. If the distributed service function determined how the authentication process is to be performed, this would limit the users of the distributed service function of an operatiny system to the one predetermined authentication scheme. Furthermore, if the predetermined authentication scheme requires remote communications with the server, there is a variety of exceptions and failures which are difficult to provide for inside the kernel of the operating system at the point where the authentication process would need to be performed. If the communica tions to the authentication server breaks, and the authentication process is in~ide the kernel, all proce~sing within the data pr~ sing system may come to a halt while the o~erating ~yRt~m kernel is waiting while trying to communicate with the remote authentication server.
Summary of the In~ tion It is there~ le an object of this invention to provide a mechanis~ whlch is general enough to interface to any of the prev1~usly known authentication schemes.
The system and method of this invention defines an interface between an operating system providing distributed service functions and a user program providing an authentication scheme. This interface is well defined and highly structured such that the kernel of the operating system does not change at all depending ,:
.~;
":~
: f-~ AT9-89-034 ll ~ ~.
upon the authentication services in the network that are ~ being utilized. A program providing an authentication - scheme can be interchangeable with other authentication , ,. "~
programs whenever the authentication scheme changes in -- the network. In addition, utilizing a user program at the remote machine to perform the authentication allows the user program to be killed, restarted, and scheduled as a regular program without affecting the performance of the underlying operating system. The complexity of authentication lies in the program and not in the kernel of the operating system.
An authentication daemon program is used at both the user initiating node and the receiving service node. A
set of message flows allows a distributed service ' function within the operating system to use the results of these authentication daemons in a way that is transparent to the distributed services function. The - ~ distributed services function merely passes the informat~on back and forth without attempting to interpret the work of the authentication daemon.
Accordingly, different authentication daemon programs using different authentication schemes can be used interchangeably within the network without affecting or changing the underlying distributed service function of the operating system. Likewise, the same distributed service function can be used within various networks having different autllentic~tion schemes in the ; authentication daemon t1r.~l in ~h network.
More specifically, A 1~uest sent to a remote service that reqt1ires autllentlcation includes an object ~ called the auth~ntic~tion information object. This -~~~ authentication inf~rmAtion .-~bject and an associated ::, authentication acknowledqement value are constructed, at c~ the requestor s n~ , by the authentication daemon from information about ~h~ requestor. The contents of these authentication ite~ and the means for their construction are preferably unknown outside of the authentication daemon itself. Th~ a~t;11enticatlon acknowledgement value is retained and the Authel1tication information object is included in the message used for the request. The service, before performing the request, extracts the - ~ , .
E
~ ,, ..~"~
t~r-' AT9-89-034 12 ~r ,' ?~ ' ' S
" ~ "
authentication information object from the request and pas~es it to a second authentication daemon running at the service's node. This second authentication daemon '"7~ ~ uses the authentication information object to authenticate the requestor according to the authentication policy supported by the daemons. The second authenti ~ cation daemon also returns a second authentication -~ acknowledgement value that is returned to the requestor in the reply to the request. This second authentication - acknowledgement is compared with the first authentication acknowledgement previously retained by the requestor to f ensure that the identity of the remote service is that of the intended service.
Brief DescriPtion of the Drawing '~ ~ Fig. 1 is a block diagram of a distributed data processing system known in the art.
Fig. 2 is a block diagram showing a stand-alone data processing system known in the art for accessing a file through system calls.
Fig. 3 is a flow diagram of the data processing - system of Fig. 2 accessing a file through a system call.
Fig. 4A is a request_for_service message which is used by a process running on a client machine in order to request that a remote service be performed.
Fig. 4B illustrates the messages that flow between the authentication agent and the requestor and between the authentication agent and tlle service.
Fig. 5 shows ~ client dAtA processing system and a server data proces~ g 8y8t ~m in a distributed data processing system h~ving a sepArate authentication agent for performing autll~ntication Fig. 6 is A flow show~ng the operations of the requestor, the aut~entication ~gent, and the service in the method of thi.~ i-lvention.
Description of the ~referred Embodiment With reference to Figure 4A, the internode message request_for_service 410 used herein is described. The request_for_service message 410 is used by a process running on a client machine in order to request that a - ':
.
' .~, ,, ,~
~~ - AT9-89-034 13 ~ 2 ~ ~:
remote service be performed. The request 411 has an opcode 413 indicating the specific operation requested.
The request 411 also has an operation field 420 used to indicate the desired operation to be performed by the server. The authentication info field 416 in the request i8 used to pass enough information to the remote machine to authenticate the process performing the request. The remote machine responds with the reply 412. The opcode field 414 indicates that this is the reply for the particular kind of request. The return code (rc) 417 in the reply is used to indicate the success or failure of the remote machines attempt to execute the request. An acknowledgement is returned in the ack field 419. The ack is used to verify that correct identification between the requesting process and the remote machine has occurred.
Fig. 4B shows the messages that flow between the authentication agent and the requestor and between the authentication agent and the service. The requestor to :
authentication agent message 520 contains information describing the requestor 531 and information describing the service 532 that the request will be sent to. The authentication agent to requestor message 521 contains an authentication information object 416 and an authentication acknowledgement value 534. The service to authentication agent message 523 contains only the authentication info object 416. The authentication agent to service message 524 contains Another authentication acknowledgement value 419 and a ~et of credentials 536 that are used by the servl~e to authenticate the requestor.
Referring to Fig. 5, a machine 503 contains a -:
~- requestor 504 that mAkes use of an authentication agent 502 through messaq~s 520, 521 The authentication agent - 502 refers to data ~tored on ~1sk 501. A second machine ~ 513 contains a "~vice 514 that makes use of an -~ authentication a~ 12 through messages 523, 524. The requestor 504 commllnic~tes with the service 514 via the request_for_service Leqllest 411 and its reply 412.
In the preferred ~mbodiment, a first machine 503 is communicating with ~ second machine 513 over a network.
, " ~ ", =,"~,""~
~ ~ AT9-89-034 14 - j. ~~ ~
-~ Rather than performing the authentication operation within the requestor process 504 and the service process ~ 514, which may be running in an operating system of the -~ ~ machines, the authentication operation is performed in - ~ the authentication agent programs 502, 512 at both of the - / nodes. These authentication agents may be user level - programs as used in systems running any type of operating system or daemons as used in systems executing the AIX
- operating system or other operating systems based on the UNIX operating system.
; '~ '7'''~ The following description refers to Fig. 4A, Fig.
- 4B, Fig. 5, and Fig. 6, concurrently. Before a process at a first machine begins to send a request 411, step 601, to use the services of a second machine, an authentication procedure must first be performed. The ~ requesting process 504 sends a message 520 to the first - ~ authentication agent 502 at the first node in order to initiate authentication, step 602. This message contains information 531 describing the process making the request :- .
and information 532 identifying the requested service.
The first authentication agent 502 uses the contents of the m~s~age 520 to construct a reply 521, step 603, returned to the requesting process, step 604. This reply 521 contains authentication information 416 and an authentication ack 534. The way in which the authentication agent uses the contents of message 520 depends upon the particular authentication policy being supported; but the way that the requesting process uses the reply 521 is independent of the policy supported by the authentication agent. The requesting process does not interpret either the auth~n~ication information 416 or the authentication ACk 534 The only operations that the requesting proces6 needs to perform with these elements are the transmi~sion of the authentication information to th~ remote service in a request, steps 605, 606 and a bitwise compari~on for equality between the authentication ~ck 534 received and retained, step 606, from the loc~; authentication agent 502, and the authentication ack ~19 ln reply 412 received from the remote service.
.-'.~,, ,~ . , ~
~ AT9-89-034 15 :~ .
In addition, the service receiving the request 411 does not need to interpret the information contained in the authentication information field 416. The service, like the requestor, treats the authentication information in the same manner independent of the authentication policy that it supports. The service always passes the authentication information to the authentication agent 512, step 607, where interpretation of this information is performed, step 608. The agent will find different contents in the authentication information message 523 depending upon the particular authentication policy being supported by the authentication agents 502 and 512. In the message 524 sent from the agent 512 to the service 514, step 609, the agent places a set of credentials 536 that describe the remote requestor in a manner that is meaningful to the service. Additionally, the agent places an authentication ack 419 in this message that does not need to be interpreted by the service. Like the authentication information, the authentication ack 419 is treated in the same manner by the service for all authentication policies supported by the authentication agents. The only operation that the service performs on the authen~ication ack 419 is returning it to the requestor in reply 412. The service makes a determination, step 610, based on the credentials 536 on .--- . .
;~ the authentication and authorization of the requestor'q ~:: r permission to request an operation 420 of the service, conditionally performing the requested operation, step 611. The results of this determination and operation are returned in a return code 417 to the requestor in a reply message 412 along with the authentication ack 419, step 612.
The requestor rece~ves t h~ reply 412 and extracts the authentication ack 419 And compares it to the authentication ack ~34 previou~ly received from the local authentication ag~lt 502, ste~ 613. If the two acks are bitwise equal, th~ requestor Is assured of the remote service s identity to the limit of the ability of the authentication pr~'o~ol supported by the agents. Upon verifying the identlty of the service, the requestor .. ~,~ , ~~ ~ examines the return code 417 to determine the outcome of ~;-.-.,/
.
2 ~' the original request, step 614, completing the request ~: . for service, step 615.
:~: The following programming design language code illustrates the processing at the authentication agent.
/* authentication agent */
LOOP FOREVER
:~ await message;
IF request is a requestor to agent message THEN
use requestor information found in message along with the service information . found in the message to construct both authentication information and an authentication acknowledgement;
send message reply containing authentication information and authentication ack back to requestor;
ELSE /* request is a service to agent message */
use the authentication info to construct a set of credentials and an authentication ack;
send message reply containing the set of credentials and the authentication ack back to service;
ENDIF;
ENDLOOP;
Copyright IBM Corporations 1989 The following programming design language code illustrates the processing at th~ requestor.
/* requestor */
/* about to make ~ request of a remote service */
construct a messaq~ containin~t A description of the process makin~J the request and a description of the remote sel:lce:
send this message ~ lthentication agent;
await reply from all~helltication agent; ~' .
,..
AT9-89-034 17 ~ 4 . ~
save the authentication ack returned in reply from agent;
construct a request for remote service, include authentication information returned in reply from the authentication agent;
~ send request to remote service;
:~ await reply from the service;
IF authentication ack in reply from service ~~~. = saved authentication ack THEN
:~ -: /* remote service authenticated */
~ ~ examine the result of the remote operation;
:-;1 ELSE
, ~, t /* remote service not authenticated */
/* ignore the returned return code */
~-~ ENDIF;
Copyright IBM Corporation 1989 ~ The following programming design language code ,': illustrates the processing at the service.
/* service */
LOOP FOREVER;
await request from a remote requestor;
extract the authentication information from the request;
send authentication information to the authentication agent;
await reply from agent;
extract credentials for remote requestor from the reply;
extract authentication ack from the reply and save it;
: rF credentials indicate that the requestor has permission to have th~ ~erver perform the operation requested ill the request from the requestor THEN
perform th~ operation:
; return co~le := the te~ults of the operation;
ELSE
., return c~ value indicating permission ., '',f ' failure;
- ENDIF;
construct a reply containing the return code and the saved authentication ack;
; - ~send reply back to the server;
ENDLOOP;
-~ Copyright IBM Corporation 1989 . . ~. .
Note, that the design suggested above employs -~ messages to communicate between the service and the 'A . ,:
authentication agent and between the requestor and the authentication agent. These messages are shown in Fig. 4B. This choice of communication interface is intended to allow multiple processes, either requestors or services or combinations of the two, running on the same node to use a single agent. In the preferred embodiment using the AIX operating system the interprocess communication facilities called message queues provide this type of interface.
These message queue facilities are described in the "AIX Operating System Technical Reference", second edition, September, 1986, order number SV21-8009, part number 74X9990, and more specifically pages 2-71 to 2-85. This allows multiple processes to share the authenti cation daemon process. By using a well defined interface based on messages, the preferred embodiment allows the daemon process to be replaced without necessitating any changes in its clients, i.e., the requestors and the services.
For example, if Kerberos based authentication is being performed, the agent will acquire a Kerberos ticket for the requestor to use the remote service.
This may involve searching id to name tables stored in the password file on disk 501 or ticket caches stored on disk 501 or memory. It may further involve communication with a remote Kerberos server using the Kerberos protocols. If Kerberos is used, the authentication info 416 contains all of the information that is needed by a service to authenticate a remote requestor using Kerberos.
~ .
To illustrate how the preferred embodiment can be , ~
~ ~used to support the kerberos protocol, the steps performed by the authentication agent are further ~; described. Message 520 to the authentication agent is ~ used by the agent to determine the requesting process s --~- associated user id. In the preferred embodiment, this id is contained in the field 531 describing the requestor - and is a small integer used to identify the user on whose behalf the request is running. The authentication agent uses this id to locate the Kerberos tickets owned by this user. In the preferred embodiment, the agent will find these tickets in a file located on the disk 501 under the name /tmp/tkt(uid) where (uid) is the actual user id. In this file, a ticket for the requested service described by field 532 may be found. If such a ticket is not found, a new ticket for the requested service is acquired by the agent. The agent acquires a new ticket by sending a ticket request to the Kerberos ticket granting service.
This ticket request is constructed according to the requirements of the Kerberos protocol as described in "Kerberos Authentication and Authorization System", - Miller, S.P. et al. Basically, the agent constructs an encrypted authenticator containing a timestamp and sends it, along with a ticket for use of the ticket granting service, to the ticket granting service in its requests for a ticket to the desired service.
In response to the ticket request, the authenti cation agent will receive from the ticket granting service ~ -cicket for the desired service and a session key for use with this service. The agent will also construct an authenticator encrypted with the session key an combine this with the ticket just received. The agent places this in the authentication info field 416 of the reply 521 that is returned to the requestor.
Additionally, the agent will construct an authentication ack from the value of the timestamp placed in the encrypted authenticator. It doe~ this by adding one to - the timestamp and encrypting it with the session key.
;, This authentication ACk i8 pl ~ced in field 534 of the reply.
The requestor, upon rec~lving the reply 521, does not need to be AW~t e thAt th~ authentication field and -: the authentication ,tck are cor-~tructed in order to take :
:
2 ~
advantage of the Kerberos authentication protocols.
Instead, the requestor treats these as abstract values, handling them in the same way independent of the way in which the authentication agents are performing authentication. The authentication info field is sent to the remote service in message 411 where it is passed in message 523 to the authentication agent running at the remote node. The remote authentication agent obtains, from the ticket, verification of the remote requestor s identity and the session key that will be used with thi~
remote requestor. This information is encrypted in the ticket in a manner which makes tickets unforgable.
Additionally, the remote agent checks the authenticator sent with the ticket, decrypting it with the session key, to find the timestamp. The timestamp is examined to make sure that this request is not a replay of a previous request. The timestamp is also used to construct an authentication ack in the same manner as was done by the first authentication agent. The authentication ack ib returned to the service in field 419 along with a description of the requestor s identity in field 536 of message 524. The ack constructed at the service authentication agent is then returned in message 412 to the requestor where it is compared to the authentication ack constructed at the requestor s node. This completes a Kerberos based authentication scheme using the preferred embodiment.
While performing the above described request, the agent communicates with the Kerberos ticket granting service. This may be running on a remote node and hence require network communication. This is not a problem for the agent since it is a regular scheduled process which can be put to sleep while awaiting a reply from the Kerberos ticket granting service without adversely impacting the performance of other processes on the system where the agent is runnin~. If the requestor had attempted to acquire the tick~ directly without going through an authenticatioll agent, the requestor might have to sleep awaiting an I/0 request. This could impact system performance ~versely if the requestor was running under kernel st~te in ~ome operating systems.
'~
~ .
Furthermore, some operating systems cannot initiate I/0 such as this while in the middle of processing a previous I/0 request for a process. This can occur if a process attempts to perform I/0 on a remote file. While in the middle of an I/0 request for a remote file, it may be discovered that authentication operations need to be performed that involve I/0 such as communicating with the Kerberos ticket granting service, causing problems in systems where a separate authentication agent is not used. In this preferred embodiment, authentication operations can be performed by the separate agent while a requesting process is in a state where it would not be able to perform the I/0 necessary for the authentication at that time.
Likewise, a different authentication policy can be used in conjunction with this preferred embodiment. When the authentication agent receives message 520 it obtains the user id from field 531. It should be noted that in the preferred embodiment all information that might be used by an authentication policy is passed in field 531 so that different implementations of a policy or different policies running in the agent will find all information needed in this field. The user id is used to search the password file on disk 501 for a password that this user has prearranged to use with the remote service identified by field 532. This password and an associated reply password are obtained by this lookup operation.
The password is placed in field 416, the authentication info fiel~l, and the reply password is placed in field 534, the authentication ack field, of the message 521.
The requestor sends the authentication info field 416 to the service where it is passed to the remote a~ent in message 523. The remote agent uses the password to search a file stored on disk 511 to locate a description of the identity of the requestor. If found, this identity information is placed in field 536 along with a reply password found in the same ~ile and placed in field 419, the authentication ~ick fi~ld of message 524. The service returns the a~it}lentlc~ition ack value to the reque~tor where it, the reply password found at the service node, is c~mpa~ed with the authentication ack .-~ ~ .
~- AT9-89-034 22 . ~
, ~, obtained from the requestor authentication agent, the reply password found in the local file. If they are the same, successful mutual authentication has occurred.
Another possible authentication policy might be implemented with a centralized authentication system.
Like the scheme just described, the authentication info field is a password passed from the requestor to the service and checked in the service authentication agent.
The authentication ack is a reply password passed to the requestor from both the requestor authentication agent and the service, which obtains it from the servlce authentication agent. Instead of finding these passwords in files on disks 501, 511, these passwords are obtained from a centralized authentication system by the agent.
Finally, the agents may be in direct communication with each other. This allows authentication policies that work outside of the network used for request for service operations to be supported. For example, a physically secured communication channel between the a~ents could be used to dynamically determine appropriate authentication info values and authentication ack values.
Requestors and services can communicate over lower cost or more available communication channels while achieving secure authentication through the use of the preferred embodiment where the agents communicate over a single secure channel.
It should be noted that the process acting as the authentication agent ln a node can act in both roles, as the requestor authentication agent and the service authenticat1on agent because both services and requestors may be running in the same machine.
Simply by disconnecting the authentication daemons, and replacing them with another authentication daemon program, the network can perform authentication using any authentication scheme. For example, the authentication daemon could perform either a centralized authentication scheme or a Kerberos authentication scheme.
Alternatively, the authelltication daemon may simply just examine a file containing passw~-l(ls.
As shown above, th~ autll~ntication of remote users by servers can be rerformed in various ways. Under some 'AT9-89-034 23 circumstances, there is very little reason to be suspicious of requests arriving at a server and low cost authentication of remote users is justified. In other environments, servers must exercise greater vigilance.
No one policy will be best for all cases. Therefore, this invention supports a range of authentication and authorization policies.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made without departing from the spirit and scope of the invention.
~,
Claims (4)
1. A system for authenticating a requestor process at a first node, of a service process running at a second node in a distributed data processing system, comprising:
a first machine at said first node;
a second machine at a second node; and communication means interconnecting, said first and said second machines;
said first machine executing an operating system;
said requestor process, and a first authentication agent program defining a corresponding first authentication policy independently of said operating system;
said first machine further including means for constructing authentication information and a first authentication acknowledgment supporting said first authentication policy;
said second machine further executing an operating system;
said service process, and a second authentication agent program defining a corresponding second authentication policy independently of said operating system.
said second machine further including means for receiving and processing said authentication information communication from said first machine to said second machine over said communication means.
means for acquiring and transmitting a second authentication acknowledgment on said communication means from said second machine to said first machine;
and wherein said first machine further includes means for comparing said first authentication acknowledgment and said second received authentication acknowledgment for determining a second authentication of said service process.
a first machine at said first node;
a second machine at a second node; and communication means interconnecting, said first and said second machines;
said first machine executing an operating system;
said requestor process, and a first authentication agent program defining a corresponding first authentication policy independently of said operating system;
said first machine further including means for constructing authentication information and a first authentication acknowledgment supporting said first authentication policy;
said second machine further executing an operating system;
said service process, and a second authentication agent program defining a corresponding second authentication policy independently of said operating system.
said second machine further including means for receiving and processing said authentication information communication from said first machine to said second machine over said communication means.
means for acquiring and transmitting a second authentication acknowledgment on said communication means from said second machine to said first machine;
and wherein said first machine further includes means for comparing said first authentication acknowledgment and said second received authentication acknowledgment for determining a second authentication of said service process.
2. The apparatus of claim 1 wherein said first authentication policy differs from said second authentication policy.
3. A method for authentication a requestor process at a first node of a service process running at a second node in distributed data processing system comprising:
executing in a first machine an operating system;
said requestor process; and a first authentication agent program defining a corresponding first authentication policy independently of said operating system;
constructing with said first machine authentication information and a first authentication acknowledgment supporting said first authentication policy;
executing in a second machine an operating system;
a service process; and a second authentication agent program defining a corresponding second authentication policy independently of said operating system;
receiving and processing with said second machine said authentication information communicated from said machine to said second machine;
acquiring and transmitting with said second machine a second authentication acknowledgment from said second machine to said first machine; and comparing with said first machine said first authentication acknowledgment and said second received authentication acknowledgment for determining a second authentication of said service process.
executing in a first machine an operating system;
said requestor process; and a first authentication agent program defining a corresponding first authentication policy independently of said operating system;
constructing with said first machine authentication information and a first authentication acknowledgment supporting said first authentication policy;
executing in a second machine an operating system;
a service process; and a second authentication agent program defining a corresponding second authentication policy independently of said operating system;
receiving and processing with said second machine said authentication information communicated from said machine to said second machine;
acquiring and transmitting with said second machine a second authentication acknowledgment from said second machine to said first machine; and comparing with said first machine said first authentication acknowledgment and said second received authentication acknowledgment for determining a second authentication of said service process.
4. The method of claim 3 further including:
deleting said second authentication agent program and substituting therefore a corresponding third authentication policy independently of said operating system.
deleting said second authentication agent program and substituting therefore a corresponding third authentication policy independently of said operating system.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US35251889A | 1989-05-15 | 1989-05-15 | |
| US352,518 | 1989-05-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2016224A1 CA2016224A1 (en) | 1990-11-15 |
| CA2016224C true CA2016224C (en) | 1999-02-16 |
Family
ID=23385456
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002016224A Expired - Fee Related CA2016224C (en) | 1989-05-15 | 1990-05-07 | A flexible interface to authentication services in a distributed data processing system |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5481720A (en) |
| EP (1) | EP0398492B1 (en) |
| JP (1) | JPH07101409B2 (en) |
| BR (1) | BR9002250A (en) |
| CA (1) | CA2016224C (en) |
| DE (1) | DE69029759T2 (en) |
Families Citing this family (135)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1992020021A1 (en) * | 1991-05-08 | 1992-11-12 | Digital Equipment Corporation | License management system |
| US5235642A (en) * | 1992-07-21 | 1993-08-10 | Digital Equipment Corporation | Access control subsystem and method for distributed computer system using locally cached authentication credentials |
| US6289390B1 (en) | 1993-08-18 | 2001-09-11 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| US5694595A (en) * | 1993-12-23 | 1997-12-02 | International Business Machines, Corporation | Remote user profile management administration in a computer network |
| US20040250083A1 (en) * | 1994-03-03 | 2004-12-09 | Barry Schwab | Secure interactive digital system for displaying items to a user identified as having permission to access the system |
| US5544322A (en) * | 1994-05-09 | 1996-08-06 | International Business Machines Corporation | System and method for policy-based inter-realm authentication within a distributed processing system |
| US5694546A (en) * | 1994-05-31 | 1997-12-02 | Reisman; Richard R. | System for automatic unattended electronic information transport between a server and a client by a vendor provided transport software with a manifest list |
| WO1996008754A1 (en) * | 1994-09-16 | 1996-03-21 | Akta N.V. | Method for protecting an apparatus against unauthorized use |
| WO1996008773A2 (en) * | 1994-09-16 | 1996-03-21 | Cirrus Logic, Inc. | Pcmcia dma data bus mastering |
| JPH08263438A (en) | 1994-11-23 | 1996-10-11 | Xerox Corp | Distribution and use control system of digital work and access control method to digital work |
| US5764890A (en) * | 1994-12-13 | 1998-06-09 | Microsoft Corporation | Method and system for adding a secure network server to an existing computer network |
| US5706516A (en) * | 1995-01-23 | 1998-01-06 | International Business Machines Corporation | System for communicating messages among agent processes |
| US5826254A (en) * | 1995-04-18 | 1998-10-20 | Digital Equipment Corporation | System for selectively browsing a large, distributed directory tree using authentication links |
| JP3262689B2 (en) * | 1995-05-19 | 2002-03-04 | 富士通株式会社 | Remote control system |
| US6901433B2 (en) | 1995-06-07 | 2005-05-31 | Microsoft Corporation | System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service |
| US5956489A (en) * | 1995-06-07 | 1999-09-21 | Microsoft Corporation | Transaction replication system and method for supporting replicated transaction-based services |
| US5774668A (en) * | 1995-06-07 | 1998-06-30 | Microsoft Corporation | System for on-line service in which gateway computer uses service map which includes loading condition of servers broadcasted by application servers for load balancing |
| US5933599A (en) * | 1995-07-17 | 1999-08-03 | Microsoft Corporation | Apparatus for presenting the content of an interactive on-line network |
| US5941947A (en) * | 1995-08-18 | 1999-08-24 | Microsoft Corporation | System and method for controlling access to data entities in a computer network |
| US5956509A (en) | 1995-08-18 | 1999-09-21 | Microsoft Corporation | System and method for performing remote requests with an on-line service network |
| JPH0981519A (en) * | 1995-09-08 | 1997-03-28 | Kiyadeitsukusu:Kk | Authentication method on network |
| US6108704A (en) * | 1995-09-25 | 2000-08-22 | Netspeak Corporation | Point-to-point internet protocol |
| US6226678B1 (en) * | 1995-09-25 | 2001-05-01 | Netspeak Corporation | Method and apparatus for dynamically defining data communication utilities |
| US5826029A (en) * | 1995-10-31 | 1998-10-20 | International Business Machines Corporation | Secured gateway interface |
| JP2977476B2 (en) | 1995-11-29 | 1999-11-15 | 株式会社日立製作所 | Security method |
| US5790785A (en) | 1995-12-11 | 1998-08-04 | Customer Communications Group, Inc. | World Wide Web registration information processing system |
| US6615251B1 (en) * | 1995-12-11 | 2003-09-02 | John R. Klug | Method for providing node targeted content in an addressable network |
| US5764887A (en) * | 1995-12-11 | 1998-06-09 | International Business Machines Corporation | System and method for supporting distributed computing mechanisms in a local area network server environment |
| US6591245B1 (en) * | 1996-02-02 | 2003-07-08 | John R. Klug | Media content notification via communications network |
| US5737523A (en) * | 1996-03-04 | 1998-04-07 | Sun Microsystems, Inc. | Methods and apparatus for providing dynamic network file system client authentication |
| US6006333A (en) * | 1996-03-13 | 1999-12-21 | Sun Microsystems, Inc. | Password helper using a client-side master password which automatically presents the appropriate server-side password to a particular remote server |
| US5751595A (en) * | 1996-03-14 | 1998-05-12 | International Business Machines Corporation | Method for building and verifying authenticity of a rule system |
| US6377994B1 (en) * | 1996-04-15 | 2002-04-23 | International Business Machines Corporation | Method and apparatus for controlling server access to a resource in a client/server system |
| US6728784B1 (en) * | 1996-08-21 | 2004-04-27 | Netspeak Corporation | Collaborative multimedia architecture for packet-switched data networks |
| US5684950A (en) * | 1996-09-23 | 1997-11-04 | Lockheed Martin Corporation | Method and system for authenticating users to multiple computer servers via a single sign-on |
| US5778174A (en) * | 1996-12-10 | 1998-07-07 | U S West, Inc. | Method and system for providing secured access to a server connected to a private computer network |
| US5832209A (en) * | 1996-12-11 | 1998-11-03 | Ncr Corporation | System and method for providing object authorization in a distributed computed network |
| US6035402A (en) * | 1996-12-20 | 2000-03-07 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
| US6839842B1 (en) * | 1996-12-27 | 2005-01-04 | Intel Corporation | Method and apparatus for authenticating information |
| US5908469A (en) * | 1997-02-14 | 1999-06-01 | International Business Machines Corporation | Generic user authentication for network computers |
| US6122631A (en) * | 1997-03-28 | 2000-09-19 | International Business Machines Corporation | Dynamic server-managed access control for a distributed file system |
| US6035406A (en) * | 1997-04-02 | 2000-03-07 | Quintet, Inc. | Plurality-factor security system |
| GB2325314A (en) * | 1997-05-12 | 1998-11-18 | Ibm | Object-oriented system for authentication |
| US5852714A (en) * | 1997-05-21 | 1998-12-22 | Eten Information System Co., Ltd. | Real time broadcasting system on an internet |
| US7290288B2 (en) | 1997-06-11 | 2007-10-30 | Prism Technologies, L.L.C. | Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network |
| US6070243A (en) * | 1997-06-13 | 2000-05-30 | Xylan Corporation | Deterministic user authentication service for communication network |
| US5996077A (en) * | 1997-06-16 | 1999-11-30 | Cylink Corporation | Access control system and method using hierarchical arrangement of security devices |
| US6021496A (en) * | 1997-07-07 | 2000-02-01 | International Business Machines Corporation | User authentication from non-native server domains in a computer network |
| US6418466B1 (en) | 1997-07-10 | 2002-07-09 | International Business Machines Corporation | Management of authentication discovery policy in a computer network |
| US6141758A (en) * | 1997-07-14 | 2000-10-31 | International Business Machines Corporation | Method and system for maintaining client server security associations in a distributed computing system |
| US6263432B1 (en) | 1997-10-06 | 2001-07-17 | Ncr Corporation | Electronic ticketing, authentication and/or authorization security system for internet applications |
| US6055639A (en) * | 1997-10-10 | 2000-04-25 | Unisys Corporation | Synchronous message control system in a Kerberos domain |
| US6092110A (en) * | 1997-10-23 | 2000-07-18 | At&T Wireless Svcs. Inc. | Apparatus for filtering packets using a dedicated processor |
| US5991879A (en) * | 1997-10-23 | 1999-11-23 | Bull Hn Information Systems Inc. | Method for gradual deployment of user-access security within a data processing system |
| US6158008A (en) * | 1997-10-23 | 2000-12-05 | At&T Wireless Svcs. Inc. | Method and apparatus for updating address lists for a packet filter processor |
| US6725376B1 (en) * | 1997-11-13 | 2004-04-20 | Ncr Corporation | Method of using an electronic ticket and distributed server computer architecture for the same |
| US6032260A (en) * | 1997-11-13 | 2000-02-29 | Ncr Corporation | Method for issuing a new authenticated electronic ticket based on an expired authenticated ticket and distributed server architecture for using same |
| US6567793B1 (en) | 1997-12-22 | 2003-05-20 | Christian Bielefeldt Hicks | Remote authorization for unlocking electronic data system and method |
| US5982892A (en) * | 1997-12-22 | 1999-11-09 | Hicks; Christian Bielefeldt | System and method for remote authorization for unlocking electronic data |
| US6151676A (en) * | 1997-12-24 | 2000-11-21 | Philips Electronics North America Corporation | Administration and utilization of secret fresh random numbers in a networked environment |
| US6298072B1 (en) * | 1998-02-19 | 2001-10-02 | Mci Communications Corporation | Real-time transaction synchronization among peer authentication systems in a telecommunications network environment |
| US6170014B1 (en) | 1998-03-25 | 2001-01-02 | Community Learning And Information Network | Computer architecture for managing courseware in a shared use operating environment |
| US6286105B1 (en) | 1998-04-01 | 2001-09-04 | 3Com Corporation | Method for implementing link-level security to enforce access privileges |
| TW425543B (en) | 1998-04-14 | 2001-03-11 | Hitachi Ltd | Data reproduction method and device, data scrambling method, data recording method and device, recorded data reproduction device and the verification method thereof, and semiconductor chip |
| US6205479B1 (en) * | 1998-04-14 | 2001-03-20 | Juno Online Services, Inc. | Two-tier authentication system where clients first authenticate with independent service providers and then automatically exchange messages with a client controller to gain network access |
| US6199113B1 (en) * | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
| DE19821911C2 (en) * | 1998-05-15 | 2000-07-06 | Siemens Ag | Method and communication system for access control through a management network having several management levels |
| DE19824787C2 (en) | 1998-06-03 | 2000-05-04 | Paul Pere | Procedure for secure access to data in a network |
| US6189103B1 (en) * | 1998-07-21 | 2001-02-13 | Novell, Inc. | Authority delegation with secure operating system queues |
| US7305451B2 (en) * | 1998-08-24 | 2007-12-04 | Microsoft Corporation | System for providing users an integrated directory service containing content nodes located in different groups of application servers in computer network |
| US7216348B1 (en) | 1999-01-05 | 2007-05-08 | Net2Phone, Inc. | Method and apparatus for dynamically balancing call flow workloads in a telecommunications system |
| US6490679B1 (en) * | 1999-01-18 | 2002-12-03 | Shym Technology, Inc. | Seamless integration of application programs with security key infrastructure |
| US6651168B1 (en) | 1999-01-29 | 2003-11-18 | International Business Machines, Corp. | Authentication framework for multiple authentication processes and mechanisms |
| US6349338B1 (en) * | 1999-03-02 | 2002-02-19 | International Business Machines Corporation | Trust negotiation in a client/server data processing network using automatic incremental credential disclosure |
| US6256737B1 (en) | 1999-03-09 | 2001-07-03 | Bionetrix Systems Corporation | System, method and computer program product for allowing access to enterprise resources using biometric devices |
| US7305562B1 (en) | 1999-03-09 | 2007-12-04 | Citibank, N.A. | System, method and computer program product for an authentication management infrastructure |
| US20010044904A1 (en) * | 1999-09-29 | 2001-11-22 | Berg Ryan J. | Secure remote kernel communication |
| US6636975B1 (en) * | 1999-12-15 | 2003-10-21 | Identix Incorporated | Accessing a secure resource using certificates bound with authentication information |
| US6918041B1 (en) * | 2000-02-23 | 2005-07-12 | Microsoft Corporation | System and method of network communication with client-forced authentication |
| US7441263B1 (en) | 2000-03-23 | 2008-10-21 | Citibank, N.A. | System, method and computer program product for providing unified authentication services for online applications |
| US6826609B1 (en) * | 2000-03-31 | 2004-11-30 | Tumbleweed Communications Corp. | Policy enforcement in a secure data file delivery system |
| US6836845B1 (en) * | 2000-06-30 | 2004-12-28 | Palm Source, Inc. | Method and apparatus for generating queries for secure authentication and authorization of transactions |
| US7536340B2 (en) * | 2000-07-24 | 2009-05-19 | Cashedge, Inc. | Compliance monitoring method and apparatus |
| US7797207B1 (en) | 2000-07-24 | 2010-09-14 | Cashedge, Inc. | Method and apparatus for analyzing financial data |
| US8086508B2 (en) | 2000-07-24 | 2011-12-27 | Cashedge, Inc. | Method and apparatus for delegating authority |
| US7013310B2 (en) * | 2002-01-03 | 2006-03-14 | Cashedge, Inc. | Method and apparatus for retrieving and processing data |
| US7146338B2 (en) | 2001-06-28 | 2006-12-05 | Checkfree Services Corporation | Inter-network financial service |
| US7383223B1 (en) | 2000-09-20 | 2008-06-03 | Cashedge, Inc. | Method and apparatus for managing multiple accounts |
| US20080015982A1 (en) * | 2000-09-20 | 2008-01-17 | Jeremy Sokolic | Funds transfer method and system including payment enabled invoices |
| CA2347581C (en) * | 2000-09-20 | 2008-07-29 | United Parcel Service Of America, Inc. | Method and apparatus for authorizing the transfer of information |
| US20030236728A1 (en) * | 2000-09-20 | 2003-12-25 | Amir Sunderji | Method and apparatus for managing a financial transaction system |
| US7254619B2 (en) * | 2000-10-13 | 2007-08-07 | Matsushita Electric Industrial Co., Ltd. | Apparatus for outputting individual authentication information connectable to a plurality of terminals through a network |
| US7412598B1 (en) * | 2000-12-29 | 2008-08-12 | Cisco Technology, Inc. | Method and system for real-time insertion of service during a call session over a communication network |
| US7237257B1 (en) * | 2001-04-11 | 2007-06-26 | Aol Llc | Leveraging a persistent connection to access a secured service |
| US7725401B2 (en) | 2001-05-31 | 2010-05-25 | Contentguard Holdings, Inc. | Method and apparatus for establishing usage rights for digital content to be created in the future |
| US6876984B2 (en) | 2001-05-31 | 2005-04-05 | Contentguard Holdings, Inc. | Method and apparatus for establishing usage rights for digital content to be created in the future |
| US8275716B2 (en) | 2001-05-31 | 2012-09-25 | Contentguard Holdings, Inc. | Method and system for subscription digital rights management |
| JP4604422B2 (en) | 2001-07-31 | 2011-01-05 | ソニー株式会社 | COMMUNICATION SYSTEM, COMMUNICATION DEVICE, AND COMMUNICATION METHOD |
| US20040236653A1 (en) * | 2002-01-03 | 2004-11-25 | Sokolic Jeremy N. | System and method for associating identifiers with data |
| US20050187867A1 (en) * | 2002-01-03 | 2005-08-25 | Sokolic Jeremy N. | System and method for associating identifiers with transactions |
| US7203845B2 (en) * | 2002-01-11 | 2007-04-10 | Cashedge, Inc. | Multiple trust modes for handling data |
| US8140854B2 (en) | 2002-02-13 | 2012-03-20 | Passlogy Company Ltd | User authentication method and user authentication system |
| US7478233B2 (en) * | 2002-05-30 | 2009-01-13 | Microsoft Corporation | Prevention of software tampering |
| EP1389750A1 (en) * | 2002-08-13 | 2004-02-18 | Canal + Technologies | Hard disk security |
| US20040243511A1 (en) * | 2003-05-28 | 2004-12-02 | Corillian Corporation | Method and apparatus to create and execute time-bound constraints |
| US20040260946A1 (en) * | 2003-06-20 | 2004-12-23 | Cahill Conor P. | User not present |
| US7290278B2 (en) | 2003-10-02 | 2007-10-30 | Aol Llc, A Delaware Limited Liability Company | Identity based service system |
| US9614772B1 (en) | 2003-10-20 | 2017-04-04 | F5 Networks, Inc. | System and method for directing network traffic in tunneling applications |
| JP4046698B2 (en) * | 2004-02-04 | 2008-02-13 | シャープ株式会社 | Data providing system and data providing apparatus |
| US20060195398A1 (en) * | 2005-02-04 | 2006-08-31 | Sanjeev Dheer | Method and apparatus for processing payment requests |
| JP4993414B2 (en) * | 2005-08-18 | 2012-08-08 | 日本電気株式会社 | Personal authentication system, terminal used in this, authentication verification device, and program |
| US20070067239A1 (en) * | 2005-09-19 | 2007-03-22 | Cashedge, Inc. | Method and Apparatus for Transferring Financial Information |
| US20070100748A1 (en) * | 2005-10-19 | 2007-05-03 | Sanjeev Dheer | Multi-channel transaction system for transferring assets between accounts at different financial institutions |
| IL171963A0 (en) | 2005-11-14 | 2006-04-10 | Nds Ltd | Secure read-write storage device |
| US20070220598A1 (en) * | 2006-03-06 | 2007-09-20 | Cisco Systems, Inc. | Proactive credential distribution |
| GB0613235D0 (en) * | 2006-07-04 | 2006-08-09 | Maidsafe Net Ltd | File system authentication |
| US8108532B2 (en) | 2006-08-29 | 2012-01-31 | Samsung Electronics Co., Ltd. | Service distribution apparatus and method |
| US8334891B2 (en) | 2007-03-05 | 2012-12-18 | Cisco Technology, Inc. | Multipoint conference video switching |
| US20080288376A1 (en) | 2007-04-27 | 2008-11-20 | Cashedge, Inc. | Centralized payment hub method and system |
| US8264521B2 (en) * | 2007-04-30 | 2012-09-11 | Cisco Technology, Inc. | Media detection and packet distribution in a multipoint conference |
| WO2008137748A1 (en) * | 2007-05-02 | 2008-11-13 | Cashedge, Inc. | Multi-channel and cross-channel account opening |
| EP2174471A2 (en) * | 2007-07-09 | 2010-04-14 | Gregor Garbajs | System and method for securely communicating on- demand content from closed network to dedicated devices, and for compiling content usage data in closed network securely communicating content to dedicated devices |
| US8250633B2 (en) * | 2007-10-26 | 2012-08-21 | Emc Corporation | Techniques for flexible resource authentication |
| US20100030687A1 (en) * | 2008-01-18 | 2010-02-04 | Cashedge, Inc. | Real-Time Settlement of Financial Transactions Using Electronic Fund Transfer Networks |
| US20090276359A1 (en) * | 2008-04-24 | 2009-11-05 | Cashedge, Inc. | Multi-Product-Multi-Channel Payment Platform System and Method |
| US9832069B1 (en) | 2008-05-30 | 2017-11-28 | F5 Networks, Inc. | Persistence based on server response in an IP multimedia subsystem (IMS) |
| WO2010022109A1 (en) * | 2008-08-18 | 2010-02-25 | Cashedge, Inc. | Money movement network hub system |
| US20100205649A1 (en) * | 2009-02-06 | 2010-08-12 | Microsoft Corporation | Credential gathering with deferred instantiation |
| US20110213707A1 (en) * | 2010-03-01 | 2011-09-01 | Fiserv, Inc. | Systems and methods for facilitating person-to-person payments |
| US8626659B1 (en) | 2012-09-28 | 2014-01-07 | Fiserv, Inc. | Facilitating presentation of content relating to a financial transaction |
| US9058240B2 (en) * | 2012-12-03 | 2015-06-16 | International Business Machines Corporation | Multi-context remote development |
| US20140188728A1 (en) | 2012-12-31 | 2014-07-03 | Fiserv, Inc. | Systems and methods for performing financial transactions |
| US10185946B2 (en) | 2014-12-31 | 2019-01-22 | Fiserv, Inc. | Facilitating presentation of content relating to a financial transaction |
| US20180063128A1 (en) * | 2016-08-31 | 2018-03-01 | Motorola Solutions, Inc | Method for automatically deleting a user password upon successful use of a multi-factor authentication modality |
| DE102022105373A1 (en) | 2022-03-08 | 2023-09-14 | Carl von Ossietzky Universität Oldenburg Körperschaft des öffentlichen Rechts | Method and system for the computer-aided management of a number of remotely controllable experiments |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4317957A (en) * | 1980-03-10 | 1982-03-02 | Marvin Sendrow | System for authenticating users and devices in on-line transaction networks |
| US4423287A (en) * | 1981-06-26 | 1983-12-27 | Visa U.S.A., Inc. | End-to-end encryption system and method of operation |
| US4578530A (en) * | 1981-06-26 | 1986-03-25 | Visa U.S.A., Inc. | End-to-end encryption system and method of operation |
| US4484306A (en) * | 1982-03-22 | 1984-11-20 | Exide Electronics Corporation | Method and apparatus for controlling access in a data transmission system |
| US4652990A (en) * | 1983-10-27 | 1987-03-24 | Remote Systems, Inc. | Protected software access control apparatus and method |
| US4672572A (en) * | 1984-05-21 | 1987-06-09 | Gould Inc. | Protector system for computer access and use |
| US4694492A (en) * | 1984-11-09 | 1987-09-15 | Pirmasafe, Inc. | Computer communications security control system |
| US4685055A (en) * | 1985-07-01 | 1987-08-04 | Thomas Richard B | Method and system for controlling use of protected software |
| JPS6253061A (en) * | 1985-09-02 | 1987-03-07 | Nec Corp | Method for preventing illegal access |
| US4800488A (en) * | 1985-11-12 | 1989-01-24 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method of propagating resource information in a computer network |
| US4916738A (en) * | 1986-11-05 | 1990-04-10 | International Business Machines Corp. | Remote access terminal security |
| GB8704883D0 (en) * | 1987-03-03 | 1987-04-08 | Hewlett Packard Co | Secure information storage |
| US4858117A (en) * | 1987-08-07 | 1989-08-15 | Bull Hn Information Systems Inc. | Apparatus and method for preventing computer access by unauthorized personnel |
| US4980913A (en) * | 1988-04-19 | 1990-12-25 | Vindicator Corporation | Security system network |
| US5077694A (en) * | 1988-12-16 | 1991-12-31 | Pitney Bowes Inc. | Distribution mailing system having a control database for storing mail handling categories common to the databases of selected mailer stations |
-
1990
- 1990-04-10 EP EP90303877A patent/EP0398492B1/en not_active Expired - Lifetime
- 1990-04-10 DE DE69029759T patent/DE69029759T2/en not_active Expired - Fee Related
- 1990-05-07 CA CA002016224A patent/CA2016224C/en not_active Expired - Fee Related
- 1990-05-14 BR BR909002250A patent/BR9002250A/en unknown
- 1990-05-15 JP JP2123211A patent/JPH07101409B2/en not_active Expired - Fee Related
-
1994
- 1994-09-14 US US08/306,224 patent/US5481720A/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP0398492B1 (en) | 1997-01-22 |
| BR9002250A (en) | 1991-08-13 |
| CA2016224A1 (en) | 1990-11-15 |
| DE69029759D1 (en) | 1997-03-06 |
| JPH07101409B2 (en) | 1995-11-01 |
| EP0398492A2 (en) | 1990-11-22 |
| DE69029759T2 (en) | 1997-07-17 |
| US5481720A (en) | 1996-01-02 |
| EP0398492A3 (en) | 1992-03-18 |
| JPH035868A (en) | 1991-01-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2016224C (en) | A flexible interface to authentication services in a distributed data processing system | |
| US7448077B2 (en) | File level security for a metadata controller in a storage area network | |
| US7010528B2 (en) | Mechanism for running parallel application programs on metadata controller nodes | |
| US5560008A (en) | Remote authentication and authorization in a distributed data processing system | |
| US5659682A (en) | Scheme to determine completion of directory operations for server recovery | |
| Walsh et al. | Security and reliability in Concordia/sup TM | |
| US8042163B1 (en) | Secure storage access using third party capability tokens | |
| US6145006A (en) | Method and apparatus for coordinating locking operations of heterogeneous host computers accessing a storage subsystem | |
| US5423044A (en) | Shared, distributed lock manager for loosely coupled processing systems | |
| EP0752635B1 (en) | System and method to transparently integrate private key operations from a smart card with host-based encryption services | |
| US8495131B2 (en) | Method, system, and program for managing locks enabling access to a shared resource | |
| US6205466B1 (en) | Infrastructure for an open digital services marketplace | |
| JPH06202998A (en) | Access control subsystem for distributed computer system and method thereof | |
| KR20010005570A (en) | An agent-implemented locking mechanism | |
| JPH04310188A (en) | Library service method for document/image library | |
| CN108073823B (en) | Data processing method, device and system | |
| JP2001503171A (en) | File transfer utility using intermediate data storage | |
| US6253236B1 (en) | System and method for serving host computer files to one or more client computer systems | |
| WO2002095588B1 (en) | Decentralized virus scanning for stored data | |
| US20030220943A1 (en) | Recovery of a single metadata controller failure in a storage area network environment | |
| US8140622B2 (en) | Parallel metadata service in storage area network environment | |
| US5101488A (en) | Method for retrieving and updating data in a real-time data base system | |
| JP4122042B1 (en) | Access authority control system | |
| KR20050029202A (en) | Asynchronous messaging in storage area network | |
| JP4191239B2 (en) | Access authority control system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |