Browse Prior Art Database

Algorithm to do Agent-Less Account Management via Provisioning, Events and Notification in Remote Resources

IP.com Disclosure Number: IPCOM000129160D
Original Publication Date: 2005-Sep-29
Included in the Prior Art Database: 2005-Sep-29
Document File: 3 page(s) / 53K

Publishing Venue

IBM

Abstract

Enterprises require identity management for managing users on various resources with users/groups, which often are used for enterprise server management. These systems sometimes provide huge repositories that are accessible to various users within the corporate network based upon policy. Often the password management and event notification during addition, deletion of change of attributes of these users is a strenuous process which involves running an agent or having a remote agent to detect various events that might have occurred on the user attributes or the user?s database. However, enterprises are very skeptical about buying software which will have installation of agents on their corporate networks of inherent security holes that it creates. Almost all of the existing systems do not support any kind of remote event notification or filtering based on attribute changes as there is no database for query or filter support on users and their attributes.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 3

Algorithm to do Agent-Less Account Management via Provisioning, Events and Notification in Remote Resources

The solution is to provide a method and system which can support remote account management and event notification using a high-level 4G language like SQL queries or LDAP filters. The goal is to enhance performance of this remote management of systems and at the same time support SQL queries and LDAP filters on the system as if it is a database or a directory server. Adding these facilities will enable better synchronization of the managed POSIX systems with the enterprise databases and lower load during modified account notification during reconciliations. This will enable significant performance benefits.

1.1 Dynamically Resource Specific Executor

There are different kinds of systems like POSIX, Windows, Databases, Directory servers and due to various system specific requirements there is a need to dynamically load an executor based upon the type of systems that we are interacting with. These are based upon executing a series of scripts that are independent of the system to which we have a secure tunneling connection with. The script is a combination of commands that are resource specific and can determine the type of system (like AIX 5.1operating system) type and then the specific subtype followed by the version of the operating system to load the required executor.

Figure: System specific version discovery

1.2 Transaction Management for Intelligent Event Notification

The next step is to perform an intelligent resource specific analysis based upon the users/group/account database (like /etc/passwd in POSIX systems) user security files which contains password specific or any other attributes that are user specific which can be controlled.

1

[This page contains 1 picture or other non-text object]

Page 2 of 3

So, depending upon the system that we are dealing with, we need to calculate the total current space of the user security files and other extra bytes that will be needed to generate the user database. Based upon the total current space that is needed, we have to make a temporary directory on a given drive which has some free space. For any other system it can be a system that loads a temporary database to do transactions using an event notification mechanism. The event notification mechanism can be any events like user addition, change of password, or group addition to a particular user etc. WS-Provisioning can be used as a communication protocol to define addition or change of attributes for a particular transaction service during runtime.

1.3 User Database Generation

The next step is to generate the user database. In the process of generation of the user database we need to make a snap shot...