1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for directory enabled, self service, single sign on user account management.
2. Description of Related Art
Systems in present art provide single sign on services for users. One example of such a system is the IBM Secure Way Policy Director (“PD”) Single Sign On (“SSO”) solution which allows users access to resources, such as secure URIs requiring user authentication, regardless of the location of the resource, and the user's credentials (resource user ID and resource password) for that resource, all of which is accomplished using only one initial login with SSO logon credential, an SSO user ID and an SSO logon password. After an initial web browser login challenge to receive and verify the SSO logon credentials, any further login challenges or requirements, from different back-end servers or other means for accessing resources, are handled transparently for the user.
The usual transaction flow for SSO solution, again using the IBM PD SSO solution as an example of an SSO production environment, is normally as follows:                1) A browser user's request for access to a resource based upon a resource name is sent to a network dispatcher, a tcp/ip switch in this example, typically behind an enterprise firewall.        2) The network dispatcher forwards the request to an IBM PD/WebSEAL Server, a web server capable of resolving, into actual resource addresses, requests for resource access based upon resource names.        3) The web server, PD/WebSEAL, validates the browser user's SSO credentials.        4) The web server, PD/WebSEAL, resolves the resource name into an actual resource address and retrieves security credentials for access to the requested resource.        5) PD/WebSEAL sends the resource request to a back-end server or an application identified by the resource address along with the resource credentials.        6) The back-end server or application validates the resource credentials, returning a webpage HTML stream corresponding to the requested resource.        7) PD/WebSEAL forwards the webpage HTML stream to the browser.        
In such a system, it is expected that a URI presented to a front-end server such as IBM's PD/WebSEAL, is to be interpreted by the server as a conventional URI containing a resource name that will not resolve directly to a network address and storage location. An additional interim step is required for full address resolution. That is, the front-end server uses the resource name from the URI as a search parameter to retrieve the actual address from a directory service such as an LDAP service or an X.500 service.
For all of this to work seamlessly, the PD System Administrators must handle all of the user management. User management includes all mappings of users' existing resource credentials, for all the various back-end servers and resources, to users' SSO IDs. Such a mapping effort can be a huge task for PD System Administrators and may require hiring many PD System Administrators.
More specifically, in typical examples of prior art, the PD System Admins have to perform the following tasks in mapping resource credentials to SSO IDs:                Define names of resources. In the case of the IBM PD example, defining resource names in accomplished by using the ivadmin command to define resource names. For example, the resource named ‘app1’ can be named by:        ivadmin>rsrc create app1 -desc “for mapping id resource test”        Create a smart junction between the PD/WebSeal server and a back-end server. A smart junction is a tcp/ip connection between a front end PD/WebSEAL server and a back-end server. A smart junction allows PD/WebSEAL to provide protective services on behalf of the back-end server.        The junctioncp command is used to create the junction:                    junctioncp>create-t tcp-h hostname options junction-point junctioncp>create-t tcp-h www.developer.ibm.com -b gso-T app1-j/app1_junction                        Manually map existing resource names, ids, and passwords to each SSO ID. This can be done either by graphical user interface menu system, such as, in the of the IBM PD, the ivconsole command, or through character command lines as for example the ivadmin command. This is a very time consuming task. For example, to map the resource having userid=AA00bb and password=footprint to the SSO id=David and then associate them to the resource named ‘app1’ requires this ivadmin syntax:                    ivadmin>rsrccred create app1 rsrcuser AA00bb rsrcpwd footprint rsrctype web user David.                        This operation has to be done for each set of resource names and resource access credentials whether by ivadmin or by ivconsole commands. That is, the process is extremely laborious regardless whether the system administrators carrying out the task use command line entries or a GUI system for making the entries.        
The initial roll-out and subsequent maintenance for a SSO solution for a large organization where there are potentially hundreds of thousands of existing users, each with multiple ids and passwords, each mapping to many resources on many different systems, all which are to be brought under the umbrella of a single user sign-on, may require many system administrators working many hours. Also, the end users may not feel comfortable divulging to another person their ID's and passwords on different systems. In fact, many organizations maintain general policies against users divulging passwords.
In present art there is no organized way for user themselves, as opposed to system administrators, to administer their own mappings of SSO IDs to system resources. It would be advantageous, in order to offload the crushing burden of SSO administration from system administrators, if there were a way for users themselves to perform their own SSO administration, including creating mappings from an SSO ID to system resources, updating such mappings, and deleting such mappings.