Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
• • 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/60—Protecting data
  • G06F21/604—Tools and structures for managing or administering access control systems
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources

Definitions

• An institution like a company or school may run a number of networked computers on which services such as e-mail, directory, database and others are offered. Generally, use of the services is restricted to a limited number of users so that user permissions must be kept and service access
• policies must be enforced. It is common that at least some of the services make use of local permissions databases in which information on users and their access privileges are kept. In this case it may be necessary to synchronize some of the information between the different databases.
• a service may be moved to a third party hoster, where it is more difficult to access the permissions information.
• a service may be split up into several sub-services or several services may be joined into one, for instance when the institution running the services is expanded or split, which means that
• some of the systems may have to be accessed from users or institutions outside of the company. This may apply to mobile workers but also to other institutions who share business processes with the first institution on a business- to-business (B2B) integration basis.
• B2B business- to-business
• the services may be accessible through a portal and different types of integrated businesses may be associated with
• predetermined permissions on a predetermined set of the services In case the status of an integrated institution changes, for instance because an existing collaboration is intensified or terminated, the permissions of the respective users of the integrated institution must be updated
• the invention achieves the given object through a system with the features of claim 1 and a method according to the features of claim 12.
• Dependent claims specify preferred embodiments.
• the system comprises a first
• the system further comprises a processing unit for determining, on the basis of the
• administration interfaces of the at least one determined service to effect access to the determined permissions.
• the global permissions database may provide an additional source of information with can be used to find out which of the services hold what specific information on a
• the system may also comprise a global permissions database for storing the determined permissions of the user.
• the global permissions database may serve as a repository for an overview of user permissions.
• the global permissions database may also be used for legal purposes in that it may be proved what access privileges were modified through the system and under what circumstances .
• the system may also comprise a third interface for accepting a response from at least one of the services about whether or not said second request to the service has been carried out, wherein the system is adapted to update the user' s
• the global permissions database may thus give a matching picture of what has actually been done to the services' permissions databases. This may be advantageously used to increase a level of coherence between the different
• the global permissions database may serve as a reference. By finding out which permissions database of which service does not comply with the global permissions database, problems in user permissions may be pinpointed.
• the global permissions database does not store a specific value of a user permission, but the existence of the corresponding attribute instead.
• the information that a user has access permission of a certain group on a certain service may be kept in the global permissions database but the user' s actual credentials may neither be kept in the global permissions database nor synchronized with the service's database.
• service access especially for users from B2B-integrated external institutions may be replicably managed through said system with said global permissions database.
• the effected access to the user's permissions in the service's permissions databases comprises write-only accesses.
• the access may be restricted to creating, amending and deleting permissions of the user from the permissions databases of the affected services. Not reading the permissions from the backend services may help avoiding a large collection of sensitive information that may be subject to unauthorized access. It may also help designing an easy to implement infrastructure with the services as a secure retrieving of sensitive
• the system may further be adapted to return, upon a
• the global permissions database may be queried to return information on software licenses that are due according to the existing user accounts. This may help keeping license expenses low.
• the global permissions database may be consulted for existing accounts when a user account is to be globally deleted, thus helping to make sure no stray user account is left on one of the services. License cost may therefore be further lowered and service security may be increased.
• the system may also be adapted to return, upon a
• the administration interface of one of the services may comprise an electronic mailbox (email) .
• the information in the mailbox may be parsed and processed automatically, e.g. as part of the service, or a human administrator may read the request in the mailbox and act appropriately.
• Electronic mail is often easily available and a human administrator may provide a flexible and adaptable connection between the request and the actual access to the permissions database of the service. Messages sent to the corresponding email address may also be forwarded to a trouble ticket system.
• one of the administration interfaces of the services may comprise a machine interface for direct access to the user' s permissions on the database of the service.
• the machine interface may e.g. use messages
• the system may be adapted to reject the first request in case predefined data associated with the first request is not available to the system.
• access to any of the services may be held back until sufficient information is present for access to all of a predetermined set of services. This may help to prevent partial execution of the first request which might otherwise lead to an unclear or even contradictive status of user permissions in the permissions databases of the services. It may also help enforcing an approval process for the request.
• the global permissions database is adapted to be located on a server that is different from a server on which the interfaces and the processing unit reside.
• the database may be kept in a separated environment which may offer additional safety features, such as interface
• the global permissions database resides on a virtual server which is hosted on a plurality of physical servers. This may help to keep an availability of the general permissions database high even in the case of failure of one of the physical servers.
• a method for managing access permissions of a user to a plurality of services comprises steps of: receiving a first request for accessing permissions of the user, determining permissions to be set in the permissions databases of the at least one service on the basis of information indicative of a first association between the user and at least one user group and a second association between the at least one user group and access permissions to at least one of the services and sending second requests to administration interfaces of the at least one determined service to effect access to the determined permissions.
• the method may advantageously be carried out on the above- mentioned system, which may comprise a computer system.
• a computer program product for carrying out said method may be executed on a processing device or stored on a computer-readable medium.
• Figure 1 shows a system for user access management
• Figure 2 shows a repository 200 for a group based permission scheme .
• Figure 3 shows another embodiment of the system of Figure 1 ;
• Figure 4 shows a schematic diagram of a method for user
• Figure 5 shows a schematic diagram of a method for
• Figure 6 shows a schematic diagram of a method for computing a number of licenses in use.
• FIG. 1 shows a system 100 for user access management.
• the system 100 comprises processing a unit 105 which is connected to a global permissions database 110.
• the processing unit 105 is also connected to a first interface 115, a second
• the interfaces 115 to 130 may be adapted to conduct information that relates to a human input or output or they may be adapted to conduct machine information such as an electronic representation of an object, a message or a signal. In further embodiments of the system 100, some or all of the interfaces 115 to 130 may be combined into one
• a first service 135 is implemented on a first backend server 140 which comprises a first permissions database 140.2, a first administration interface 140.4 and a first service interface 140.6.
• second and third services 145 and 155 are implemented on second and third backend servers 150 and 160, respectively.
• One or more users 165 may communicate with the servers 140, 150 and 160 through the associated service interfaces 140.6, 150.6 and 160.6 to obtain access to the services 135, 145 and 155, which may e.g. comprise services of e-mail, database, access, purchase, organization and management services.
• the servers 140, 150 and 160 are called backend servers because to users 165 who stand outside of an organization that runs the system 100 and/or the services 135, 145 and 155, access to the servers 140, 150 and 160 is performed from external, usually through a security component such as a packet
• Administration interfaces 140.4 and 150.4 of first and second backend servers 140, 150 are each connected to the second interface 120 of the system 100. In order to manage
• a corresponding request is sent to the first interface 115 of system 100.
• the system 100 After passing optional tests pertaining to the presence of required data, e.g. user name and user group, the system 100 sends out messages through the second interface 120 to effect the requested change of information in the permissions databases 140.2 and 150.2.
• a confirmation is sent back to the system 100 from the services 135, 145 so that it is known in the system 100 that the requested access has been carried out.
• the system 100 is able to effect the user permissions access directly through a machine-to-machine communication through the second interface 120 and the administration interfaces 140.4, 150.4 of backend servers
• the access to user permissions in the database 160.2, which is associated to third service 155 may be carried out through a human administrator 170.
• service 145 is an e-mail or a similar groupware or message delivery service.
• an e-mail or corresponding other human- readable message is passed to the second service 145 for delivery to the human administrator 170.
• the service interface 150.6 may be used instead of the
• administration interface 150.4 After the administrator 170 has received the message, he effects the requested user permissions change through the administration interface 160.4 in the third permissions database 160.2. A confirmation that the requested change has been carried out or a notification that at least some of the changes could not be carried out may be sent back by the administrator 170 to the system 100 through the e-mail service 145. In a different embodiment, the notification may be automatically generated and sent from the service 145 to the system 100. In many cases, it is not necessary that the permissions of the user 165 correlate between permissions databases 140.2, 150.2 and 160.2. The object for system 100 is rather to create and delete accounts for the user 165 in an
• a user account is created for said user 165 in each of the services 135, 145 and 155.
• the creation and furnishing with certain access rights is
• the global database 110 is queried for which of the services 135, 145 and 155 an account for the user 165 exists and then corresponding deletion requests are sent out to administration interfaces 140.4, 150.4 and 160.4 of servers 140, 150 and 160, respectively.
• the global permissions database 110 may be queried through third and fourth interfaces 125, 130 for management purposes. For instance, it may be interesting to see on which of the services 135, 145 and 155 a user 165 has access permissions. This may be done in order to obtain an accounting for user licenses that have to be paid for each of the services 135, 145 and 155.
• a corresponding query may be done on a per-service basis. For instance, the number of users 165 who have an account on a predetermined one of the services 135 through 155 may be queried through one of the interfaces 125, 130 of system 100. Also, a history of changes to user permissions, either on a per-user basis or a per-service basis, may be queried from the global permissions database 110 from the system 100 using one of the interfaces 125, 130.
• Figure 2 shows an exemplary repository 200 that is organized in a first matrix 205 and a second matrix 210. Through the matrices 205 and 210 an access permissions management may be enforced that is compatible with system 100 of Figure 1.
• the first matrix 205 shows how users 165 are associated to user groups 215. In a vertical direction the users 165 are shown and in a horizontal direction user groups 215 are shown. A user 165 is associated to a group 215 where a mark is shown in the cell that is defined by the user 165 and the user group 215.
• the second matrix 210 shows how services are associated to user groups 215.
• the second matrix 210 holds columns for a ticket tool service 230, electronic mail (email) 235 and a telephone service 240.
• the systems associated to columns 230- 240 correspond to systems 135, 145 and 155 in Figure 1.
• Lines of the second matrix 210 are grouped to functionalities "mail” 245, "mobility” 250 and "security” 255.
• the functionality is comparable to a role or a task and serves to organize the function a user 165 acts in.
• the functionalities may be permeable, allowing a user 165 to be moved or
• Cells of the second matrix 210 hold the names of those user groups 215 that are associated with access permissions to the corresponding service.
• the "mail" functionality 245 comprises all tasks that may be carried out in order to ascertain proper functioning of the mail system 235.
• User groups 215 with access permissions to the mail system 235 comprise group "postmaster" 220 and "mail_support” 225. Users 165 who are members of those groups will therefore have permission to access the email system 235 and the ticket tool 230.
• group access permissions to services by functionalities it is possible to organize permissions of users 165 to the services 230-240 according to a business perspective .
• a user 165 may be assigned the "mail" functionality 245.
• User 165 is therefore assigned to user groups "postmaster” and "mail support", enabling him to use the ticket tool 230 and the email system 235.
• Permissions as defined in the second matrix 210 are given such that user 165 is enabled to perform the "mail" functionality 245 he is assigned to but his permissions will not reach to systems the user 165 does not need for his functionality.
• the functionality 250 he will be made member of other user groups 215 that are specific to the new functionality. In the process, he may lose his membership to the roles 215 that are specific to the "mail" functionality 250.
• the groups the user 165 must be removed from can be determined by looking up in the second matrix 210 the user groups 215 associated with the functionality the user 165 is removed from.
• the process of a user 165 entering or changing a functionality may be subject to an approval process, as will be explained later with respect to Figure 4.
• the access permissions scheme displayed m Figure 2 does not take into account fine granular permissions that may be given to a user 165 or group 315 on the corresponding services 230- 240.
• FIG. 3 shows another embodiment of the system 100 of Figure 1.
• System 100 is shown in the centre of Figure 3.
• a number of backend servers 305 to 335 provide services such as identity and access management, reporting, charging and billing, contract data, incident and problem management, change and configuration management and access management.
• each service is running on a server, where a server may comprise one or more physical computers and possibly additional hardware such as a storage system.
• a server may comprise one or more physical computers and possibly additional hardware such as a storage system.
• interface 340 may be comprised by the system 100. There may also be a dedicated interface 345 for communicating with a backend server 350 that is hosted at a third party, i.e.
• the first interface 115 of the system 100 is used to
• the customer portal 365 may also serve as central access point for external users 165.
• the customer portal 365 may provide a web-based interface and the user 165 may use this interface to place a request to access his/her permissions on the various backend servers 305 to 335 and 350 to the first interface 115.
• the same first interface 115 may also be used from inside of the installation. While some such requests for access will be handled by the services 305 to
• 335 and 350 e.g. password change
• other requests for access may touch a security policy or the creation or deletion of a user account on a service 305 to 335 and 350 may be handled through system 100.
• a customer interface 370 provides business-to-business interfaces to permit integration of the services 305 to 335 and 350 over the bounds of said installation.
• the second interface 120 may be used to communicate with the customer interface 370.
• the system 100 may be adapted to support a first process 375 for managing access approval. An access request received through the first interface 115 may be run through the access-approval process before any permission information is touched on any of the backend servers 305 to 335 and 350.
• System 100 may also support a second process 380 of
• the second process 380 may be used to organize information inside of the global permissions database 110 according to the requirements of access rights documentation 355 and provisioning 360 of access rights.
• the same process 380 may also control the exchange data via the third and fourth interfaces 125, 130.
• Figure 4 shows a schematic diagram of a method 400 for user access management.
• Method 400 may be executed on system 100 of Figures 1 or 2 or implement the first process 375 of access approval shown in Figure 3.
• the request may comprise a call for user creation, deletion or modification of permissions for one or more services.
• the received request implies only the writing of information to one or several permissions databases of services 140, 150, 160, 305 and 335 and 350.
• step 420 approval for the requested access is sought in a step 420. This may comprise interaction with a human administrator. Should the approval not be granted, method 400 terminates in step 415. In one variant, the approval step 420 may be omitted or automatic verification and approval may be given .
• the backend servers hosting the requested services are identified.
• the information and possibly the documents that are required for access to said backend servers are determined.
• Such information may comprise a user name and address and documents may comprise a picture of the user or a written consent to the intended usage of user specific data.
• step 440 As long not all required information and documents are present, more information and/or documents are retrieved in a step 440. This may comprise sending back a request for said missing entities to the person or system that initiated method 400 in step 405. When it is found in step 435 that all information and documents required are present, method 400 proceeds with a step 445. In step 445, messages are sent to the administration
• the sent messages effect the access to said user permissions so that afterwards, user permissions in the permissions databases of the servers 305 to 335 and 350 reflect the desired changes in a concerted fashion.
• responses from said backend servers are received and evaluated so that it is clear which user permission access has succeeded and which one has failed.
• Information that is indicative of the user permissions access is then stored in the global permissions database 110 in a following step 455. This operation may comprise appending an entry to an access history.
• a user 165 may have access to a first service in order to be able to use a second service.
• the messages sent out in step 445 may comprise several parametrized messages to several services.
• a first message may be sent to the administration interface of the corporate directory server with the request to grant access of said user 165 to a predetermined kind of data
• a second message may be sent to the administration interface of the e-mail server with the request to create a mailbox for the user 165.
• the mailbox may be created with predetermined parameters for options like a quota or maximum message size and the predetermined parameters may stem from the group policy determined in step 410.
• Figure 5 shows a schematic diagram of a method 500 for retrieving an audit trail.
• Method 500 may be carried out on system 100 of Figures 1 and 2 and may be comprised by the second process 380 of documentation and provisioning
• a request for an audit trail is
• step 515 the global database 110 is queried, the information is retrieved and, where necessary, rearranged so as to fit an expected response format for the request received in step 505.
• step 520 said information is returned and method 500 terminates.
• Figure 6 shows a schematic diagram of a method 600 for computing a number of licenses in use.
• Method 600 is also adapted to be carried out on system 100 of Figures 1 and 2 and may be comprised by second process 380 of documentation and provisioning orchestration of Figure 3.
• the licenses may be software licenses for a given service, e.g. e-mail.
• a request for a number of licenses is received.
• the request may be directed at the number of licenses in use for a specific user 165 or a predetermined group of users 165.
• the request may alternatively be directed at the number of licenses that are in use by a predetermined service 135, 145, 155.
• step 610 the required information is
• the global database 110 is queried in a step 615 and a response to the query is reformatted where
• the retrieved and reformatted information is then returned in a step 620 after which method 600 terminates.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Signal Processing (AREA)
• Computer Networks & Wireless Communication (AREA)
• Computing Systems (AREA)
• Theoretical Computer Science (AREA)
• General Health & Medical Sciences (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Software Systems (AREA)
• Bioethics (AREA)
• Health & Medical Sciences (AREA)
• Automation & Control Theory (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=44064681

Family Applications (1)

Country Status (2)

Families Citing this family (2)

Family Cites Families (4)

• 2011
  • 2011-03-24 WO PCT/EP2011/054538 patent/WO2012126528A1/en active Application Filing
  • 2011-03-24 EP EP11711824.0A patent/EP2689377A1/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events