Identify target goals.
Make sure that you and others working on the project use the same terminology. For example, password synchronization and single sign-on are two different technologies.
Also, make sure that the meaning and usage of “metadirectory” are clear as you communicate with others on the project.
Clearly write down the big picture of what you are trying to do.
Discover the business process.
The process that you are trying to automate with Identity Manager is often already defined and written down.
Be careful. Even if a process exists, people commonly don’t fully understand how it works.
Clearly write down what the business process is, and clarify the process to others.
Identify all systems.
Identify the systems and all connectivity interfaces with existing systems. Doing this can lead to an increase or decrease in the originally planned systems that you had in mind.
Keep in mind that telephony systems often don’t have an easy API interface.
SQL-based systems sometimes have a very complex database relationship model. It’s possible that nobody in your environment understands how the model actually works.
Identify how many Identity Vaults you will need, where they will be located, and what they will connect with.
What to Do In Designer: You can use the Designer Architect Modeler while you are doing this process. It’s very helpful to build a diagram of your enterprise and capture key information about each of your systems and each of the users that administer those systems.
As you start a project, keep in mind that the “people management” aspect is vital to your ultimate success. As you identify systems, you need to start the wheels in motion for getting access to those systems in the various departments of the organization.
Define high-level data sync flow.
Define the different information types that you want to synchronize. It’s common to have different employee types (for example, internal or external).
Be aware of the relationships and dependencies between information of different types (for example, employee, manager, organization, or location).
Doing this step well is critical in helping you to define your data and policy needs.
What to Do In Designer: You can design these data flows in the Dataflow view while you are in the Architect mode or Developer mode.
Define objects and attributes to synchronize.
After knowing the data and relationships, you can break the data into specific Identity Vault and Application object types and attributes.
Define merging behavior, passthrough, notification, and reset of attributes.
Identify and derive additional operations based on an original event.
Identify attributes for match, creation, and placement behaviors.
What to Do In Designer: You can use the Task view to capture all of this information or add it to a section in a Document Generation form. One advantage for having it in the Task view is that you can then mark off your tasks as you move into the implementation phase and write the policy to deliver on your requirements.
You can also include any file (word processing document, spreadsheet, presentation) in your Designer project through the Navigator view. By default, the Navigator view launches the appropriate native application to edit and view that document in a way that integrates into Designer, as long as the platform supports it. If you prefer to, you can also configure Designer to use a different editor. This view gives you many options for the types of documents you can include and edit in a Designer project.
Write a Requirements Assessment Document.
Document all of the above findings.
Write a high-level acceptance proposal.
Describe the infrastructure.
Create a project timeline.
What to Do In Designer: You can use Designer’s Document Generator to capture your high-level design, systems, and basic data flows. You can also fill in sections in the document or create your own sections that describe the project.
Fill in the technical details.
Take the high-level diagram that you created in the Architect mode and transition it to a detailed diagram that you can configure your entire solution with.
Configure servers and authentication information on the Identity Vaults.
Create driver sets and drivers. Determine how many driver sets are on each vault. Define what drivers are associated with each driver set, and what servers the driver set is running on. Run the Driver Configuration Wizard on each driver.
Develop driver policies. Make sure that you define and use Global Configuration Values (GCVs) as much as possible. Doing this leads to easier maintenance.
What to Do In Designer: With the Modeler in Developer mode, use the Outline view, Policy Flow view, and properties dialog boxes on all objects, Filter editor, Schema Map editor, E-mail Template editor, Policy Builder editor, and other functionality.
NOTE:The preceding six steps assume that you are building an identity solution from the beginning.
However, Designer is also intended for working on existing solutions. You can create a project and import existing driver sets, drivers, policies, and configurations. Designer lets you easily diagram and manage all components as one complete solution. You can edit existing policies or configurations, add new elements, and then redeploy.
Using Designer on existing solutions has several advantages. You can do the following:
Work in a high-productivity development environment.
Easily work off-line.
Have everything on your local file system for versioning and backup.
Simulate.
Generate documentation for your projects.
Unit test.
Use project-proposal documents and requirements as a basis.
Test all policies. In addition to the Designer tools, you can deploy the project (or parts of it) into a test environment to test more fully.
Generate a report on results.
What to Do In Designer: Use the Designer Policy Simulator to do much of your policy simulation and debugging. It is very easy to use, helps you catch a lot of issues, and is ideal for off-line development.
Build a production environment.
As much as possible, mirror existing production environments.
Make sure of the following:
All Identity Manager engines and drivers are installed.
All servers have correct IP addresses.
The applications your drivers will connect to are in place.
As an extra precaution, you might want to deploy to a full test environment or staging environment first. If this is the case, all of the above steps apply to configuring that environment.
What to Do In Designer: To make the next steps easier, you can click a button, get a full PDF document of all of the configuration details of your project, and use that document as you set up your machines and software.
Make sure that the data is clean before you deploy.
Ensure the following:
Each user has a unique and correctly formatted ID.
All users and other objects are where you expect them to be.
No duplicate objects exist.
No extra or unnecessary objects exist.
Deploy to production.
Make sure that the production systems are working well. For example, machines are up and running.
Before you deploy, make sure you have done adequate testing on your project.
If you have previously configured the project to deploy to a separate test or staging environment, you need to change the IP addresses on each Identity Vault (and maybe some GCVs) to successfully deploy to the production environment.
After you deploy, quickly test and redeploy all or any part of the project with any fixes you need.
What to Do In Designer: In the future, more will be done in Designer to help in this area. For now, the following tips can help in this process.
Do a full copy of the project in the Project View.
This lets you fill in the new IP addresses for production and leave the old ones alone, so that you can have a project called Staging and another called Production. The disadvantage is that if you change something such as a policy in one, you need to change it in the other to keep the policies in sync. Designer does let you copy/paste between projects to make synchronization easier.
Always use GCVs to keep your policies easily portable.
If you have a value that is environment-dependent, you only need to edit a GCV when switching to a different environment.
Use the Modeler’s Table editor.
This editor is a quick and easy way to get to objects of a certain type (for example, all of your Identity Vaults or all of your servers), see their values, and edit them.
Document your project.
Document Generation is always available to help you understand your configurations.
Document, back up, and maintain the production system.
What to Do In Designer: Run the Document Generator and save the document.
Make a copy of your project in the Project view. A copy is useful in case you ever need to return to that state or set up a production system again for any reason.
Over time, you will certainly add systems and policies, and make changes in your production environment. You can use iManager for the management of your system (especially if the change is more of an administrative task) and then reimport those changes into your local Designer project.
If the changes you need to make are more suited for a development environment, (for example, policy debugging, policy development, or adding new systems) then continuing to use Designer is the best practice. After each change, you can redeploy the project or just the elements that have changed.
As you version and extend your project over time, remember to always use Document Generation as your paper trail.