Patent Application
20080046576
The invention comprises the following components:
The client application component (10) is a software component that relies upon an access control component (12) to assist in the process of authenticating the users of the client application. A user will typically begin the authentication process to a client application by providing their userid and an authentication credential, such as their password. The client application component will provide the userid and credential to the access control component via an application programming interface (API), a system call, or a network protocol. The access control component will respond to the client application component with an indication of whether the user has been successfully authenticated.
The access control component (12) is a software component that provides an authentication and access control service to the client application component (10). The access control component will establish connections to one or more directory server (16) or directory proxy server (14) components. In order to authenticate a user who is accessing a client application, the access control component will submit one or more DAP or LDAP requests over these connections, in which the request locates a directory entry for the user, and either validates the user's authentication credential against that directory entry, or retrieves the stored authentication credential from the directory entry.
The directory proxy server component (14) is a software component that forwards requests it receives from the access control component to one or more directory servers for further processing. When the directory proxy server forwards a request to a directory server or receives a response from a directory server, the directory proxy server will write the parameters of the request or response in its access log. The directory proxy server is used in the situation of directory servers which do not generate an access log of search or bind requests. In this situation, a directory proxy server can be placed between the access control and the directory server, and the directory proxy server will be configured to generate the access log.
The directory server component (16) is a software component that implements the server side of a directory access protocol, such as DAP or LDAP. The directory server component maintains a directory information tree of one or more directory entries. Each user of a client application is represented by a directory entry in the directory information tree.
The log parsing agent component (20, 22) is a software component that collects and processes access log information. A log parsing agent is installed on each server computer where a directory server or directory proxy server is installed, to collect access log information from that directory server or directory proxy server. The log parsing agent retrieves patterns from the LPA database (18, 24), which is configured with a set of patterns that indicate the forms of bind and search operations generated by the access control component when it authenticates a user. Each log parsing agent has access to a pattern for each directory-enabled access control component present in the deployment that relies upon the directory server or directory proxy server whose log is monitored by that log parsing agent. The behavior of the log parsing agent component is illustrated by the flowchart of
The LPA database component (18, 24) is a software component that maintains the persistent state of the log parsing agent component. The LPA database can be implemented as a relational database, which comprises five tables: the authenticator table (130), the bind pattern table (132), the search pattern table (134), the element set table (136) and the log status table (138). The structure of these tables is illustrated by the diagrams of
There is one row in the authenticator table (130) for each access control component (12) in the deployment. Rows in this table are created by the administrator. The primary key of this table is the AUTHENTICATOR ID column. The columns of this table are:
Examples of values used in the STATUS column in rows in the authenticator table (130) include “disabled”, to indicate that the access control component has been temporarily disabled, and “deleted”, to indicate that the access control component has been permanently disabled. A NULL value in the STATUS column indicates that access control component is active.
There is one row in the bind pattern table (132) for each access control component in the deployment which uses a bind request to authenticate a client. Rows in this table are created by the administrator. The primary key of this table is the PATTERN ID column. The columns of this table are:
There is one row in the search pattern table (134) for each access control component in the deployment which uses a search request to authenticate a client. Rows in this table are created by the administrator. The primary key of this table is the PATTERN ID column. The columns of this table are:
There is one row in the element set table (136) for each record to be transferred to the unused account detection component. Rows are added to and removed from this table by the log parsing agent component. The primary key of this table is the ELEMENT ID column. The columns of this table are:
There is one row in the log status table (138). This row is updated by the log parsing agent component. The columns of this table are:
The unused account detection component (26) is a software component that receives element sets from one or more log parsing agent components (20, 22) via a network connection. The network connection comprises an application layer protocol exchange, carried within a secure sockets layer session layer protocol exchange which provides encryption, such as the secure sockets layer protocol Transport Layer Security (TLS) protocol described in the document “The Transport Layer Security (TLS) Protocol Version 1.1” by T. Dierks et al of April 2006, carried within the Transmission Control Protocol (TCP) on an Internet Protocol (IP)-based computer network. The unused account detection component updates the UAD database (28) identity and agent tables. The unused account detection component is configured with a time interval for user inactivity, for example 30 days, and a time interval for log parsing agent contact, such as one day. The behavior of this component is illustrated by the flowchart of
The UAD database component (28) is a software component that maintains the persistent state of the unused account detection component. The UAD database can be implemented as a relational database, which comprises two tables: the identity table (240) and the agent table (242). The structure of these tables is illustrated by the diagram of
There is one row in the identity table (240) for each user that accesses the client application component. The primary key of this table is the USER ID column. The columns of this table are:
Initially, rows are added to the identity table (240) for each user. In each row, the initial value of the LAST LOGIN ATTEMPT DATE column is set to the current date and time, and the value of the STATUS column is set to NULL.
There is one row in the agent table (242) for each log parsing agent. The primary key of this table is the AGENT ID column. The columns of this table are:
The processing components of this invention can be implemented as software running on computer systems on an enterprise computer network.
The log filtering agent component comprises a single thread of execution. At step 62, the thread will create an empty element set by initializing the element set table (136). At step 64, the thread will read the log checkpoint from the log status table (138) and compare this checkpoint with the access log of the directory server or directory proxy server. At step 68, the thread will test whether there are unread access log records which the log parsing agent has not yet processed. If there are no unprocessed log records, then at step 70 the thread will wait for log updates from the directory server or directory proxy server, or until a timeout period is reached.
At step 72, the thread will traverse each log record in the log of the directory server or directory proxy server that has not yet been handled by the log parsing agent. At step 74, the thread will parse the record from the log. At step 80, the thread will test whether the log record is a bind operation or a search operation. If it is a bind operation, then the thread will search the bind pattern table (132) for a row in which: the value of the SOURCE ADDRESS column, if not NULL, matches the network address of the directory access protocol client, the value of the BASE DN column is a suffix of the distinguished name of the request, the value of the MATCH TYPE column matches an attribute type in the least significant relative distinguished name of the bind request, and the value of the STATUS column is NULL. If it is a search operation, then the thread will search the search pattern table (134) for a row in which: the value of the SOURCE ADDRESS column, if not NULL, matches the network address of the directory access protocol client, the value of the BIND DN, if not NULL, matches the distinguished name by which the client authenticated to the directory server, the value of the SEARCH BASE column, if not NULL, matches the baseObject field of the search request, the value of the SEARCH SCOPE column matches the scope field of the search request, the value of the FILTER PATTERN column matches the filter of the search request, the value of the MATCH TYPE column is an attribute type of an equality filter in the filter in the search request, the value of the REQUESTED TYPES column, if not NULL, matches the value of the attributes field of the search request, and the value of the STATUS column is NULL. At step 84, the thread will test whether one or more rows were found in either the bind pattern table or the search pattern table. If no search was performed or no rows were found, then at step 86 the thread will test whether the operation is a delete operation or an operation, such as a modify, which changes the state of the user. If so, then the thread will continue at step 90. If no search was performed, no rows were found, and the operation is not a delete operation or does not change the state of the user, then the thread will continue at step 92. If the search was performed and one or more rows were found, then at step 88, the thread will process record by pattern to extract the userid of the user being authenticated. At step 90, the thread will add an element to the element set table (136) for the record. After the records have been handled, the thread will continue at step 100.
At step 100, the thread will test whether it has a connection to the unused account detection component. If it does not have a connection, then at step 102 the thread will establish a connection to the unused account detection component. If the connection establishment failed, then at step 106 the thread will report an error, and continue to step 66. At step 108, the thread will send the element set to the unused account detection component over the connection. At step 110, the thread will test whether the unused account detection component successfully received the element set. If the unused account detection component did not successfully receive the element set, then at step 112 the thread will report an error; at step 114 the thread will close the connection, and the thread will continue at step 66. Otherwise, at step 116, the thread will close the connection, clear the element set, and save the log state to the log status table (138). The thread will then continue at step 66.
The unused account detection component (26) has a single thread of execution. At step 152, the thread will set the initial value of the LAST LOGIN ATTEMPT DATE column in each row of the identity table (240) to the current date and time, and set the initial value of the LAST CONTACT DATE column in each row of the agent table (242) to the current date and time. At step 156, the thread will wait, either until a connection is attempted from a log parsing agent, or until a timer event occurs. The timer is set to the log parsing agent contact interval. If a timer event occurred, then the thread will continue at step 190. Otherwise, at step 160, the thread will receive an element set from a log parsing agent over the connection, and then close the connection. If the element set transfer failed, then the thread will loop back to step 156. Otherwise, at step 164 the thread will set the value in the LAST CONTACT DATE column for the row in the agent table (242) for the log parsing agent to the current date and time. At step 166, the thread will traverse the elements in the element set. At step 168, the thread will parse the element, extract the userid of the user from the element, and search the identity table (240) for a row in which that userid matches a value of the USER ID column. At step 180, the thread will test whether a row was found. If a row is found, then at step 182 the thread will test whether the date and time in the value of the LAST LOGIN ATTEMPT DATE in the row is more recent than the date in the element. If an identity is found and the date and time in the row is not more recent than the date and time in the element, then at step 184, the thread will set the value of the LAST LOGIN ATTEMPT DATE column of the row in the identity table to the date and time of the element. At step 186, the thread will loop back to step 168 until all elements of the element set have been processed.
At step 190, the thread will search the agent table (242) for rows in which the value of the STATUS column is NULL. If one or more rows have a value in the LAST CONTACT DATE that is older than the configured log parsing agent interval, then the thread will loop back to step 156. Otherwise, at step 194 the thread will traverse the log parsing agents represented by the rows of the agent table (242). At step 210, the thread will compute the time difference between the current date and time and the last contact date and time of the agent from the value of the LAST CONTACT DATE column. After all the rows for the log parsing agents have been traversed, at step 214, the thread will select the largest of the time differences calculated, add the user inactivity time interval to this largest time difference to form a sum, and set an inactivity date and time to be this sum subtracted from the current date and time. At step 216, the thread will search the identity table (240) for rows in which the value of the STATUS column is NULL. At step 218, the thread will traverse each user record in the identity table. At step 220, the thread will compare the user's last login date and time from the value of the LAST LOGIN ATTEMPT DATE column with the inactivity date and time. At step 224, the thread will test whether the value of the LAST LOGIN ATTEMPT DATE column is earlier than the inactivity date and time. If the value is earlier, then at step 226 the thread will update the row in the identity table by setting the value of the STATUS column to “inactive”. At step 228, the thread will loop back until each record has been processed. The thread will then continue at step 154.
Many different embodiments of this invention may be constructed without departing from the scope of this invention. While this invention is described with reference to various implementations and exploitations, and in particular with respect to systems for monitoring the last login times of users with accounts in a distributed directory service, it will be understood that these embodiments are illustrative and that the scope of the invention is not limited to them.
This application claims the benefit of PPA Ser. No. 60/838,077 filed Aug. 16, 2006 by the present inventor, which is incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60838077 | Aug 2006 | US |
