CHAPTER 8
User Account Creation

And Adam gave names to all cattle, and to the fowl of the air, and to every beast of the field.

—Genesis 2:20

With some components of the framework in place, you can begin building on it even before fully deploying. Now that we have resources and a directory designed, we can begin assembling the users from their current hiding places, or bringing them into the enterprise brand new, and in either case establishing identifying attributes for determining access. There are various methods for doing so, and you may in fact use any combination of them. If you have built a new authoritative source, you are likely to populate it in bulk to begin with, and then go into maintenance mode using regular synchronization. If Oracle Virtual Directory becomes your authoritative source, there is not much maintenance beyond any schema changes you may find necessary later.

If you already have a user directory in place, you will still likely need to provide additional attributes or groups to govern the access you will be granting those users, meaning that you will perhaps be overlaying an extended schema. This is a common use of Oracle Directory Services: assimilating and augmenting an existing schema.

Let’s walk through possible options for creating user accounts in preparation for provisioning, authentication, and authorization:

Bulk loading

One-time reconciliation

Identity management interface

Human Resources integration

Customer service

Self-registration

It’s a good possibility that you will be employing bulk loading or full reconciliation to start, using the IdM interface for maintenance, HR integration for incremental reconciliation, and self-registration as well. These are not mutually exclusive. Regardless of the methodology employed, you must construct rules around how that method is to be used, to ensure that you achieve the desired result, which is a source of user truth that can safely and compliantly feed the entire IAM process. I’ve seen large uploads go badly because certain data elements were not formatted properly, indexing was not complete, or referential integrity was destroyed because not all the necessary elements were present during processing. One word you hear from experts when they talk about populating the source of truth is: make sure the data is “clean,” and that word is itself ambiguous.

Bulk Loading

You came to the company with a whole bunch of other people. Your company was bought by another company. Or your broker, like mine, was sold by its parent company to a bigger broker. Or your bank, like mine, was bought by another bank, and then that bank was bought by a third bank. The acquired party provided the acquiring party with giant dumps of employee and customer data. Sure, you’re still on your old bank’s system, but the new parent wants to immediately present you with promotional offers, as well as pleas to stick with them through the occasionally bumpy transition.

It could be as simple as moving users from one database or directory to another, or else growing or collapsing domains. Regardless, it’s not something you do haphazardly, although this does not have to be complicated. The Oracle suite has a number of tools and utilities for bulk loading of user data. Since the most common user directory within Oracle’s customer base is the Oracle Internet Directory, let’s start with that. OID is not just an LDAP interface. It is a directory server in the traditional sense. It also consists of an underlying Oracle database, which allows it to manage far more objects than a traditional LDAP server. Naturally, it serves as a DIT (Directory Information Tree), and provides synchronization with source data, as well as a catalog engine for indexing. It also includes Oracle Directory Services Management (ODSM) for centrally maintaining the directory itself. This management interface, by the way, can also be used for maintaining Oracle Virtual Directory (OVD) and Oracle Directory Server Enterprise Edition (ODSEE, the former Sun LDAP). And finally, OID provides the bulkload command-line tool, for pushing large numbers of records into the directory server.

The bulkload command-line tool (which uses the Oracle SQL Loader) requires input files to be in LDIF format, which has been defined by the Internet Engineering Task Force (IETF). Information specific to the format is available at their web site. In summary, there are “sub-formats” for adding and deleting entries, as well as for modifying schema. Sequencing of entries is important in that parent entries should precede child entries; that is, build the house and then let the kids move in. Any object classes or attributes relative to an entry must exist in the target schema or be added as part of the load before the entries themselves can be loaded.

The bulkload tool operates in three phases:

Check, in which it validates all records in the LDIF file for schema and duplicates. Any errors are reported, and must be corrected before the process can complete.

Generate, in which the input data is converted into a format that is acceptable to the SQL Loader.

Load, in which the converted data is loaded into the directory server.

There are two modes for bulk loading, incremental and just plain bulk. Incremental allows you to append data to existing directory entries. While not as fast as bulk loading mode, it is still faster than other methods. Incremental is meant for small data loads. What makes directories perform so well for lookups is the heavy indexing. It’s the same reason you don’t use them for transactional data, because with every new entry, all pertinent indices must be updated. Because incremental loading uses SQL inserts, it automatically updates established indices, and therefore this process can impact performance.

Bulk loading mode is meant for just that, bulk, that is, large numbers of entries. For this reason, existing indices are dropped, and indexing itself is not used during the load. Think of it this way. If, for each entry, you need to index ten fields, then with each insert, you would load a record, update ten indices, then repeat. The performance would not be optimal. Instead, bulk loading shoves the data in, and then goes back and updates the indices after the fact.

As I indicated early in this section, mergers and acquisitions often prompt this kind of bulk assimilation of users, so that the identities of multiple organizations can become participants in a single identity framework. Mergers are also common reasons for using the next method, reconciliation.

One-Time Reconciliation

For the sake of assimilating users from a source in order to launch the new framework, Oracle Identity Manager can perform a one-time reconciliation with legacy systems as a form of user discovery. This brings those user accounts into the OIM directory. Once this process is completed, OIM becomes the system of truth for identity.

This one-time reconciliation is considered a full reconciliation. In other words, it brings over all accounts so that you have a foundation for your identity system. Subsequent reconciliations will be incremental events, meaning you will retrieve only new, modified, and deleted accounts. Yes, that sounds wrong, bringing over deleted accounts. What you are doing is reconciling the fact that a deleted user will no longer participate in your IAM framework. However, in the era of compliance, you will rarely delete users, at least not for a long time after they’re gone. You will deactivate and de-provision them. In the meantime, in that window between deactivation and deletion, chances are you will be reporting on them, which is a lot easier when there’s a shell to work with.

Identity Management System

Oracle Identity Manager has a full interface for creating, provisioning, and managing users. It can also be used for assigning them to groups and organizations, unlocking accounts, and resetting passwords. For the sake of customer service, limited views can be created for this purpose as well. If a user already exists in the HR or authoritative source, but does not exist in OIM for the sake of access-related identity, the OIM interface is well-suited, since HR identity is not necessarily the same as the OIM identity if you are not synchronizing in real time.

In some organizations, OIM is in fact used as the HR system. However, this is not what it was designed for. Robust human resource apps, such as PeopleSoft, track more than identities. For example, they can track applicants for jobs, including the entire life cycle of contact, resume, interviews, and status, all the way through to hiring and the necessary transitions. PeopleSoft and its brethren also interface with payroll, can determine based on where you live how you are taxed, track if you’ve been sent the appropriate tax documents, and everything else related to an employee life cycle beyond the access management that OIM is designed for.

That said, you can customize OIM to track these items via workflow, and the schema and landing pages can also be modified to handle additional attributes, but you may consider whether it’s worth it to reinvent the wheel.

HR Event

After bulk loading, after the original population of your authoritative source, the ideal methodology for maintaining your user directory is a proper human resources channel, automated by incremental reconciliation. It is the way most organizations do it, and should in fact be a funnel, if not the source of truth. If nothing else, it should be the starting point that ultimately feeds the source of truth. The human resources manager, hiring manager, or other designated body fat-fingers you into PeopleSoft, Siebel, or another package per the prescribed procedure, and this is where the entire process of identifying and provisioning begins.

I see in many enterprises that the human resources application is not the source of truth, but simply the mechanism for populating it. The HR directory provides status, drives benefits and salary, and manages reviews and other organizational needs, but is often not the source for enterprise identity and access. If a user’s life cycle indeed starts with HR, then the information must be extracted and turned into the driver for IAM.

Within the design phase, you specified the process for provisioning. There is a starting point, then the initiation of the workflows that place a new user in all the appropriate targets, including the approvals and connectors necessary to enable the user across the resources that are appropriate for his role and/or job title. But the initiating resource, the HR feed, serves as the beginning for the other resources. As we discussed in Chapter 7 when we covered design, resources are more than members of a list of applications or databases. Their definitions include the mechanism and frequency for communication, the adapters that manage the interactions, and the specifics of how they are extracted from and updated.

The most common methodology for using HR as the starting point is defining an HR Feed for OIM to reconcile with. As we discussed in the previous chapter, you can define scheduled tasks that run as needed to perform a variety of functions, and one of the most common is reconciliation with a human resources package or database. This reconciliation may be incremental, extracting only the changes since the previous reconciliation (the recommended method), or a full reconciliation for the sake of a completely clean copy of all data (not recommended). There are connectors available in OIM for a number of packages, including PeopleSoft and SAP. Additional adapters can be created through the OIM adapter factory for custom packages. Incremental changes for existing users may consist of mapping data columns to directory attributes, but in the case of a new user account, you may be updating more than one target, all of which may need to be aware of each other.

You may create different tasks or processes to reconcile for different specific purposes that may be scheduled or on demand. For example, a normal task is to take a new user, read his department, and assign him to the standard workflow. An alternate task is to take a new user, read his department, and assign him to a workflow specific to that department.

Customer Service

You’re the newest client of your bank, phone company, or Internet provider. Their friendly service folks keyboard in your name and assign you a user id. Or perhaps, as at my bank (which uses my company’s software), you already have an identity, but you’re not yet enabled for online service, so you visit the web site, click to register, and provide account information that must be verified before you can be fully enabled. In other words, you’re data, not really a user. Administrators can create views within OIM allowing customer service personnel to manage users in a customer-focused directory. Another option would be synchronizing a customer service database with OID, or via a scheduled task in OIM. This process would be virtually identical to synchronization with the HR system.

You might also create a customer-service-oriented interface to OIM, with a limited or specialized menu of functions (create or manage users, create and track requests).

Self-Registration

Self-registration is more than simply filling out a form and jumping in the pool. A user must identify himself sufficiently to gain the trust of the host, providing information that should be validated by a process and/or human approvers. There are micro and macro considerations. Let’s start with the user experience first.

Within Oracle Identity Manager, you must first decide whether to allow self-registration at all. Some organizations do not permit users to request an account to begin with, and even after they have been established, may not allow them to request their own resources. This is obviously a corporate decision.

User profile pages come with default fields, some of which you may allow a user to edit, and some you may not. For example, an existing user may request membership in a group, which they may or may not be granted, but cannot explicitly place themselves in that group. The profile page should be configured to display all required and optional fields, with emphasis on those values that reviewers (whether human or process) need in order to decide whether to approve the registration. Approvers also have pages, and they must review all required values. So while this sounds like common sense, let’s say it anyway: Make sure that any fields required on the self-registration page also appear on the approver pages.

You can also build custom forms that submit requests to the identity service behind OIM. Submitting a registration request should subsequently kick off an approval workflow, so that the required parties can review the request and rule accordingly. Since a registration is the first step in identity, it may be wise to make this workflow an all-or-nothing proposition; if any step is refused, then the entire request chain is null. Consider the following.

Because I’m a customer in good standing, I decided to stop going into the lobby at my bank, and visited my bank’s web site to register as an online user. I provided enough identifying data to create that online account. I received a message saying that approval would take up to twenty-four hours. It was in fact two hours, and was likely an automated process, which generated an e-mail notification of the approval. I was then able to view my accounts, and request the ability to actually move money around. That second request prompted a call from a customer service representative asking if I was happy with the experience (but probably really checking up on me and verifying that it was me by virtue of the phone number on file). It also sent me a final e-mail. But that’s workflow in action, with approvals and notifications. I received e-mails telling me I was approved, and a customer service rep was notified to call me. Above all, nothing was instantaneous (in other words, approvals had to take place), although it was timely and efficient.

When creating that first account, you may be assigned a default password provided to you by e-mail, which seems like a security hole, but is quite common because you have to authenticate with your e-mail first to get to the default password. If you are enabled to log directly in to OIM, you will be prompted the first time in to change that password. You will also be asked to choose and answer security questions. OIM comes with default questions, but administrators can configure others.

Universal Requirements

No matter how your initial user account is created, Oracle Identity Manager can mandate security measures and consistency with current policies as well as legacy requirements. User names can be reserved so that they cannot be reused, even if their original owners are gone. This is a relatively good practice, to avoid auditing confusion and for the sake of convenience in the event a previous employee returns. A manufacturing customer of mine, the largest employer in its home city, keeps user names reserved indefinitely because of employees who have come and gone multiple times.

OIM can generate user names compliant with corporate policy, including the ability to increment similar user names, as when your company employs multiple John Smiths. OIM also supports localized notification templates based on a user’s configured, preferred language.

OIM can randomly generate passwords compliant with the policies of the target systems, and can configure these passwords for one-time use, requiring users to change those passwords the first time in. This may also be set up as a requirement of the database or directory you authenticate against, and enforced by Oracle Access Manager. New users are subject to approvals, attestation, password policies, and other security requirements.

Users can be created with a start date (when they can log in and manage their own OIM account), end date (when that account is disabled), provisioning date (when their target accounts are to be created), and de-provisioning date (when those target accounts are to be killed off). Let’s revisit those all briefly. You know when the account was first instantiated. You know when it is to be completely disabled. You know when that account should be enabled to interact with business accounts, when it should be disconnected from the business. There are several use cases in which you might pull a user out of the business apps, but not wipe him out entirely, such as a scheduled departure in which the user is still receiving some type of benefits, mail, or other communications.

While it’s possible to continue using disparate password policies across multiple directories, it is definitely not advisable. Why should you have umpteen expirations, password formats, and interfaces to visit? As someone who accesses literally hundreds of possible applications using only two passwords (with reduced sign-on, rather than completely single sign-on), I can attest to the improved user experience and efficiency. Best practices dictate a centralized password policy, with format, expiration, and enforcement across all (or most) apps. The Oracle Identity Manager Design Console allows you to specify a password policy regarding what a password should contain and how long it lives before expiring, as shown in the following illustration.

It’s a sad fact that, if you don’t enforce policies on the makeup of a password, a large number of people will (guaranteed) use “123456.” This is not an exaggeration. Every incremental step-up in a password format, such as requiring a mix of upper- and lowercase, or the inclusion of numbers or special characters, weeds out another layer of amateur hackers.

Another important last stage of setup is security questions. Please read this short section carefully. It’s actually very important. These are the questions that can verify that you are who you say you are when you’re locked out or have forgotten your password (we’ll cover that later), so you can re-enable yourself without having to call and wait for the help desk. Security questions are a vital part of self-service as well as security. Remember, you’re protecting yourself as well as the organization when you set up your security questions, so don’t take them lightly. They can actually present more of a system vulnerability than your password itself.

During the 2008 American election season, Vice-Presidential candidate Sarah Palin’s Yahoo account was hacked by somebody who simply clicked the forgotten password link on her login page to bring up her security questions, the answers to which were all easily found on a Google search (a hazard for someone with a high profile). This is an example of having to protect people from themselves.

In general, it’s a bad idea to let people create their own questions. Give them a choice of company-invented questions. Provide at least a couple of dozen, from which they must choose five or six. When it’s time to use them, present three at random, so it’s not the same three every time. A hacker should never be told which of the security questions he got wrong, and if it’s not the same three every time, it gets a lot tougher to get the right combo.

And while the system can’t determine if your answers are accurate, it can employ logic to ensure the answers aren’t easy to guess by virtue of being too vanilla, all the same, or just lazy shortcuts. Otherwise you get something like this:

Q: What year did you buy your first car? Red

Q: What’s your spouse’s mother’s maiden name? Red

Q: What is the air speed velocity of an unladen swallow? Red

Q: What’s your favorite color? Color

Because of its pedigree in handling this process, Oracle Adaptive Access Manager is now integrated with the overall suite to support logic behind even the answers to security questions, including preventing those answers from being part of the user’s name, or part of the question itself.

If you have configured role and/or access policies to dynamically grant roles and rights, then the next steps may be handled without any additional intervention, meaning the initiation of workflow to provision the new account, at least for those default roles such as Employee, Contractor, Benefits Holder, Hourly Worker, and so on. Additional grants may rely on requests by the hiring manager or the new user himself. But at least the foundation has been built by creation of that initial account. Once you’re known, you must then be given the keys to the resources that you were hired to manipulate in the first place. So we’ll discuss that next.