Self-management of access control policy

A self access management system allows users to self-grant access rights to resources. An access policy specifies which users have what levels of access to which resources. In addition to specifying conventional access rights, the access policy specifies that at least one user has self management rights to at least one resource. A request from a user to access a resource to which the user does not have conventional access rights is received. The access policy is consulted, to determine whether the user has self management rights to the resource. If so, it is further determined whether criteria specified by the self management rights for accessing the resource are met. Responsive to the criteria being met, the access policy is updated to grant the user access rights to the resource, according to the terms of the self management rights.

TECHNICAL FIELD

This disclosure pertains generally to access control systems, and more specifically to allowing users to self-grant access rights to network resources under appropriate circumstances.

BACKGROUND

Network managers and other IT engineers spend a significant amount of their time responding to user requests for access to network resources. Most of these requests are routine in nature, and they are also usually urgent. Given erratic work hours and geographically distributed project teams, these requests can arrive at any time of day or night. As a result, IT engineers are always on call, and spend a large amount of their time responding to these user requests. This interferes with their ability to perform less urgent but potentially more important longer term projects. In addition, because IT engineers frequently become overwhelmed with access requests, there is often a delay in processing the requests and responding to the users. This is problematic for the users, as the requests are typically urgent in nature. It would be desirable to address these issues.

SUMMARY

A self access management system allows users to self-grant themselves access rights to network resources, under specific circumstances. An IT engineer provides an access control policy which specifies which users have what levels of access rights to which network resources, for example within an enterprise. In addition to specifying conventional user access rights, the access control policy specifies that at least one user has self management rights to at least one network resource. Self management rights allow users to self-grant access rights to the corresponding network resources. A request from a user to access a network resource to which the user does not have conventional access rights is received. The received request can specifically indicate that the user is requesting to self-grant access rights to the network resource. The request can also be directed to an IT engineer, requesting that the user be granted conventional access rights to the network resource, in which case the request is intercepted in route. In either case, the access control policy is consulted, to determine whether the user has self management rights to the network resource. If so, it is further determined whether criteria specified by the self management rights for accessing the network resource are met. This can involve, e.g., determining whether the user occupies a specific position within an enterprise organizational structure, or whether the user requires a reference from a second user with access rights to the network resource. If the user requires such a reference, only in response to receiving the reference from the second user is it determined that the criteria specified by the self management rights for accessing the network resource have been met. Where the criteria specified by the self management rights for accessing the network resource are not met, access rights are not self-granted to the user. On the other hand, responsive to determining that the criteria have been met, the access control policy is updated to grant the user access rights to the network resource, according to the terms of the self management rights. These terms can specify to grant the user limited access rights to the network resource and/or to grant access rights for a limited duration of time, after the occurrence of which the access control policy is again updated to terminate the rights. An indication can be automatically sent to a third party such as the IT engineer, specifying that the user requested self management rights to the network resource, or that the user successfully obtained access to the network resource by using self management rights.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an exemplary network architecture100in which a self access management system101can be implemented. The illustrated network architecture100comprises multiple clients103A,103B and103N, as well as multiple servers105A and105N. InFIG. 1, the self access management system101is illustrated as residing on server105A. It is to be understood that this is an example only, and in various embodiments various functionalities of this system101can be instantiated on a client103, a server105or can be distributed between multiple clients103and/or servers105.

Clients103and servers105can be implemented using computer systems210such as the one illustrated inFIG. 2and described below. The clients103and servers105are communicatively coupled to a network107, for example via a network interface248or modem247as described below in conjunction withFIG. 2. Clients103are able to access applicants and/or data on servers105using, for example, a web browser or other client software (not shown).

AlthoughFIG. 1illustrates three clients and two servers as an example, in practice many more (or fewer) clients103and/or servers105can be deployed. In one embodiment, the network107is in the form of the Internet. Other networks107or network-based environments can be used in other embodiments.

FIG. 2is a block diagram of a computer system210suitable for implementing a self access management system101. Both clients103and servers105can be implemented in the form of such computer systems210. As illustrated, one component of the computer system210is a bus212. The bus212communicatively couples other components of the computer system210, such as at least one processor214, system memory217(e.g., random access memory (RAM), read-only memory (ROM), flash memory), an input/output (I/O) controller218, an audio output interface222communicatively coupled to an external audio device such as a speaker system220, a display adapter226communicatively coupled to an external video output device such as a display screen224, one or more interfaces such as serial ports230, Universal Serial Bus (USB) receptacles230, parallel ports (not illustrated), etc., a keyboard controller233communicatively coupled to a keyboard232, a storage interface234communicatively coupled to at least one hard disk244(or other form(s) of magnetic media), a floppy disk drive237configured to receive a floppy disk238, a host bus adapter (HBA) interface card235A configured to connect with a Fibre Channel (FC) network290, an HBA interface card235B configured to connect to a SCSI bus239, an optical disk drive240configured to receive an optical disk242, a mouse246(or other pointing device) coupled to the bus212e.g., via a USB receptacle228, a modem247coupled to bus212, e.g., via a serial port230, and a network interface248coupled, e.g., directly to bus212.

Other components (not illustrated) may be connected in a similar manner (e.g., document scanners, digital cameras, printers, etc.). Conversely, all of the components illustrated inFIG. 2need not be present. The components can be interconnected in different ways from that shown inFIG. 2.

The bus212allows data communication between the processor214and system memory217, which, as noted above may include ROM and/or flash memory as well as RAM. The RAM is typically the main memory into which the operating system and application programs are loaded. The ROM and/or flash memory can contain, among other code, the Basic Input-Output system (BIOS) which controls certain basic hardware operations. Application programs can be stored on a local computer readable medium (e.g., hard disk244, optical disk242) and loaded into system memory217and executed by the processor214. Application programs can also be loaded into system memory217from a remote location (i.e., a remotely located computer system210), for example via the network interface248or modem247. InFIG. 2, the self access management system101is illustrated as residing in system memory217. The workings of the self access management system101are explained in greater detail below in conjunction withFIG. 3.

The storage interface234is coupled to one or more hard disks244(and/or other standard storage media). The hard disk(s)244may be a part of computer system210, or may be physically separate and accessed through other interface systems.

The network interface248and or modem247can be directly or indirectly communicatively coupled to a network107such as the Internet. Such coupling can be wired or wireless.

FIG. 3illustrates a self access management system101, residing in the system memory217of a computer system210according to some embodiments. As described above, the functionalities of the self access management system101can reside on a client103, a server105, or be distributed between multiple computer systems210, including within a cloud-based computing environment in which the functionality of the self access management system101is provided as a service over a network107. It is to be understood that although the self access management system101is illustrated inFIG. 3as a single entity, the illustrated self access management system101represents a collection of functionalities, which can be instantiated as a single or multiple modules as desired (an instantiation of specific, multiple modules of the self access management system101is illustrated inFIG. 3). It is to be understood that the modules of the self access management system101can be instantiated (for example as object code or executable images) within the system memory217(e.g., RAM, ROM, flash memory) of any computer system210, such that when the processor214of the computer system210processes a module, the computer system210executes the associated functionality. As used herein, the terms “computer system,” “computer,” “client,” “client computer,” “server,” “server computer” and “computing device” mean one or more computers configured and/or programmed to execute the described functionality. Additionally, program code to implement the functionalities of the self access management system101can be stored on computer-readable storage media. Any form of tangible computer readable storage medium can be used in this context, such as magnetic or optical storage media. As used herein, the term “computer readable storage medium” does not mean an electrical signal separate from an underlying physical medium.

As illustrated inFIG. 3, the self access management system101enables users307, under certain circumstances, to self-grant themselves access to network resources309for a limited period of time. To facilitate this, an IT engineer301can grant such self management rights305to users307where appropriate. The granting of such rights305can but need not be based on the role of the user307within an enterprise organizational hierarchy. The self-granting of access to network resources309allows the user307to access the resource309immediately, thereby meeting the urgent need for access. The IT engineer301can then process the access requests303after the fact, at a convenient time when the situation is less urgent.

Conventionally, access to network resources309is granted to a minimal group of users307, based on need. The actual group of users307who might legitimately desire at least limited access to a given resource309at some later time is generally larger. Conventionally each additional user307outside of the initial, minimal group desiring access to the resource309must make a request303to the IT engineer301. The IT engineer301then processes these requests303on a case by case basis, as described above.

As illustrated inFIG. 3, when an IT engineer301configures a conventional access control policy313granting a minimal group of users307access to a particular resource309, the IT engineer301can also assign additional users307self management rights305to that resource309. Users307with self management rights305can subsequently self-grant themselves temporary access rights to the resource309by going through the proper workflow as described below.

The IT engineer301can assign self management rights305to an individual user307or group of users307as desired. The IT engineer301may assign self management rights305based on organizational relationships as defined, for example, in a corporate organization chart, as decisions concerning the granting of access to users307outside of the initial group are often conventionality made based on such relationships. For example, suppose the members of a development team (a group of users307) are granted read access to a particular file server (a network resource309). The IT engineer301can also grant self management rights305to related users307and teams, who perhaps should not be granted read access by default, but who are closely related enough in function to the development team so that future access to the file server may become desirable. Users303granted self management rights305in this scenario could include QA engineers under the same engineering director, developers on other teams in the same division, or anyone above the development team in the management hierarchy. In addition, the IT engineer301can (but need not) configure self management rights305such that a requesting user307must obtain a reference311from another user307that has conventional access rights to the resource309before self-granting himself access. For example, a QA engineer could obtain such a reference311from a developer on the team. Self management rights305can also be configured without requiring such a reference311. For example, whereas it might be desirable to require a QA engineer to obtain a reference311from a developer before accessing the file server, it is unlikely that such would be required of the CTO.

As illustrated, the IT engineer301operates an access control configuration interface315in order to configure user access control policy313to network resources309. This access control configuration interface315can be in the form of a graphical and/or other type of user interface, such as a command line, configuration file, etc. The IT engineer301can use the access control configuration interface315to configure conventional access control policy313, as well as self management rights305to resources309. In granting self management rights305, the IT engineer301can configure which users307are to have self management rights305to which resources309, the length of time for which the self management rights305are to be effective, whether the user needs a reference311to self-grant access, and what level of access can be self-granted (e.g., read only, read-write, read-write-execute, etc.). The IT engineer301can configure self management rights differently for different users307and resources309as desired.

As illustrated, an access rights receiving module323receives an access control policy313configured via the access control configuration user interface315. Note that in addition to conventional access rights, the access control policy313can also comprise self management rights305, as configured by the IT engineer301. The access rights receiving module323maintains the received access control policy313, for example by storing it in an access control database317(or other suitable storage mechanism). Note that the IT engineer301can update, edit, overwrite and otherwise make changes to the access control policy313from time to time, as desired. The access rights receiving module323receives and stores such updates. Thus, the access rights receiving module323always maintains the current access control policy313.

As users307attempt to access network resources309, an access enforcing module325(instantiated, for example, in the form of conventional access enforcing points) accesses the access control policy313stored in the access control database317, and uses conventional access control functionality to make determinations as to whether to allow particular users307access to particular resources309, based on their access rights. As described in more detail below, a self access granting module327also accesses the access control policy313from this database317to determine whether a particular user307can self-grant himself access to a particular resource309.

As illustrated, an enterprise organizational structure321(e.g., a company organizational chart, an enterprise organizational hierarchy, etc.) can be stored in an organizational database319(or other storage mechanism). The enterprise organizational structure321can comprise information such as reporting structure and job titles. The IT engineer301, the access enforcing module325, and the self access granting module327can all access the information in the organizational database319to verify organizational relationships between users307, either for creating or enforcing the access control policy313.

When a user307with self management rights305to a given network resource309wishes to access that resource305, it is the case that either the user307knows or does not know that s/he has self management rights305. In the first scenario, the user307makes a request303to the self access granting module327, which accesses the current access control policy313to confirm that the user does have self management rights305to the resource. If so, the self access granting module327initiates the workflow to grant the user307the temporary access to the resource307, according to the criteria and terms of the self management rights305. If the self management rights305specify that the user307needs a reference311in order to obtain the rights, the self access granting module327so informs the user307(e.g., through a user interface, email, SMS, or another form of messaging). The user307can then operate a reference obtaining module329to request a reference311from another user307with reference granting authority. This reference311request can be made via email, instant messaging, etc., and the user307with reference granting authority can send the requested reference311to the self access granting module327in the same types of ways. If the self management rights305specify that the user's307access to the network resource309is contingent on the user307having a certain relationship or position within the enterprise organizational structure321, the self access granting module327can access the enterprise organizational structure321from the organizational database319, and confirm that the user307meets the specified criteria.

Once the criteria specified by the access policy are met, the self access granting module327grants the user the limited access, as per the terms of the self management rights305. In order to do so, an access control policy updating module331updates the stored access control policy313to indicate that the user307has the rights in question. The user307can subsequently access the network resource309according to the terms of the self-granted self management rights305without having to disturb the IT engineer301in real-time, or wait for the IT engineer301to grant conventional access. When a user307grants himself access to a resource309, he will have access for a limited period of time as per the terms of the self management rights305. This period will be long enough to satisfy his immediate need for access to the resource309. When the limited period of time has transpired, the access control policy updating module331can update the stored access control policy313to terminate the user's307self-granted access rights.

In some embodiments, an indication sending module323automatically sends an indication333to the IT engineer301that the user307has requested or successfully administered self management rights305for the resource309. The IT engineer301can process these indications333in a convenient way at a convenient time, for example in batch during regular business hours.

In a case during which the user307does not know that s/he has self management rights305to the resource309, the user307simply sends a request303to be given conventional access rights to the IT engineer301. In some embodiments, the self access granting module327intercepts such requests303, and determines if the requesting user307has self management rights305to the target resource309. If not, the request303is simply passed on to the IT engineer301. However, where the user303in question does have self management rights305to the resource309, the self access granting module327communicates this information back to the user307(e.g., via user interface, email, instant message, etc.), and initiates the workflow for the self-granting process described above.

As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the portions, modules, agents, managers, components, functions, procedures, actions, layers, features, attributes, methodologies, data structures and other aspects are not mandatory or significant, and the mechanisms that implement the invention or its features may have different names, divisions and/or formats. The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or limiting to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain relevant principles and their practical applications, to thereby enable others skilled in the art to best utilize various embodiments with or without various modifications as may be suited to the particular use contemplated.