1. IDM Administrative Objects
   1. Types
      1. User objects
         1. • Provide users access to one or more resources and manage user account data on those resources
         2. • Assign roles, which set user access to various resources
         3. • Are part of an organization, which determines how and by whom user accounts are administered
         4. By default, IDM stores seven data attributes for each user. 4 of these attributes are contained within the User object and three are contained within the User Extended Attributes configuration object.
            1. Under User Object
            2. name
            3. email
            4. idmManager
            5. password
            6. Under User Extended Attributes
         5. Topic
      2. Organization objects
         1. Organization objects allow you to perform the following tasks:
            1. Logically and securely manage user accounts and administrators
            2. Limit access to resources, applications, roles, and other Identity Manager objects.
      3. Resource and Resource Group objects
         1. • Resources: Store information about how to connect to a resource or system on which accounts are created
         2. • Resource Groups: A group of resources with a specific order of creation and deletion of user accounts
      4. Policy objects
         1. • Define and enforce the structure of accounts and passwords
         2. • User-based policies:
            1. • Include the Default Lighthouse Account Policy (a policy of policies)
            2. • Are assigned to a user directly or indirectly
         3. • Resource-based policies:
            1. • Include the AccountId Policy and Password Policy
            2. • Enforce parameters, such as length, complexity, and use of dictionary words, when creating accounts and passwords
      5. Role objects
         1. Represent an identity user types
         2. Allow resources to be grouped and assigned to users
         3. Typically, roles represent user job functions.
         4. Roles define a base set of resources and resource attributes for users
         5. They can also define relations between other roles, for example, roles that contain or exclude other roles
         6. Users can have one or more roles
         7. Role objects consist of:
            1. List of resources
            2. List of aprovers
            3. List of notifications
            4. List of excluded roles
      6. Capability objects
         1. • Are a group of rights that the user is authorized to execute on an object type
         2. • Enable a user to perform administrative actions
         3. • Are typically assigned based on job responsibility (such as password resets and account approvals)
         4. • Capabilities distinguish and end-user from an administrator in IDM
         5. • Capabilities can contain other capabilities, therefore creating a logical grouping of rights. For instance, the Password Administration Capability contains the Change Password Administrator capability and the Reset Password Administrator capability.
         6. • Can be extended for customer-specific needs
      7. Form objects
         1. Forms are associated with a page that contains rules about how the browser should display user attributes on that page.
         2. Form objects especify which fields are visible on the page and which HTML form elements are used to represent each field.
2. What is IDM?
   1. IDM consists of the business process and technologies for managing the life cycle of an identity and its relationship to business applications services
      1. Involves account creation, modificagtion, disablement, and deletion across heterogeneous platforms
      2. Use delegated administration, workflow, rules, and policies
      3. Supports end-user self-service password reset and provisioning
      4. Provides centralized auditing and reporting
   2. Identity Life Cycle
      1. New Users
      2. Change events and user support
      3. User Leaves
   3. Business Drivers
      1. Reduce Costs
      2. Improve quality of service
      3. Business: Open Access
      4. Security: Minimize Risk
      5. Health information portability and accountability act
      6. Sarbanes-Oxley
      7. European Data Protection Directive
      8. Gram-Leach-Bliley Act
   4. IDM Products
      1. Enterprise
         1. Identity Manager
         2. Access Manager
         3. Directory Server
         4. Identity Auditor
      2. Collaborative Enterprise
         1. Federation Manager
         2. IDM SPE
         3. Open SSO
   5. Components
      1. Unified Identity Console
         1. Delegated Administration
         2. Role and Policy management
         3. Self-service interface
         4. Audit
         5. Reporting
      2. Automated User Provisioning
      3. Password Management
      4. Identity Sinchronization
      5. Identity Platform Services
         1. Auto-Discovery
         2. Virtual Identity
         3. Rules Engine
         4. Dynamic Workflow
         5. SPML Interface
      6. Agentless adapters
   6. Features
      1. Core features
         1. Comprehensive provisioning
            1. Connectivity to more than 50 types of resources
            2. Digital and non-digital assets
            3. Workflow-based solution
      2. Resource Connectivity
      3. Workflow
         1. Multiple processes that control creation, update, enabling, disabling and deletion of users accounts
         2. Integration with third-party tools
         3. Notification and approval handling
         4. Complex, multi-stage provisioning execution and error handling
         5. Interactive request processes:
            1. Form wizards
            2. Multi-page user entry
      4. Virtual Identity
      5. Features of Virtual Identities
         1. Lightweight, yet extensible
         2. Real-time interaction with managed resources:
            1. > Ability to generate reports on native data in resources
            2. > No complex replication infrastructure
            3. > Immediate update to resource
         3. Virtual identity composition:
            1. > Key information for each resource
            2. > List of resources
            3. > Basic information (name, email)
            4. > Identity Manager ID
      6. Identity Synchronization
         1. IDM provides automatic synchronization of identity data across multiple resources.
      7. Password Management
         1. Synchronization to multiple resources
         2. Centralized password reset
         3. • Self-service password reset and synchronization
         4. • Convenient access through:
            1. > Web browser
            2. > Interactive Voice Response (IVR) system
            3. > Microsoft Windows client log-in (CTL-ALT-DEL)
         5. • Automated password policy enforcement:
            1. > Password history store
            2. > Password exclusion dictionary
      8. User Management
         1. • Forms and rules that encapsulate business logic
         2. • Centralized solution for applying user policies
         3. • Web-based self-service ― Delegation to end-users to make profile changes and initiate request
         4. • Multi-step, complex provisioning:
            1. > Convenient, web-based approval steps
            2. > Available to managers, HR representatives, and IT administrators
3. Reports
   1. Reports are considered a special category of task. As a result you wirk with reports in two areas of the IDM Administrative Interface:
      1. Reports
         1. From here, you define, run, delete, and download reports. You can also manage scheduled reports.
      2. Tasks
         1. After you define reports, go to the Task page to schedule and manipulate report tasks.
   2. Reporting Categories
      1. • Reporting on Identity Manager objects:
         1. > Summary Reports
         2. > Account Index Reports
            1. Not as much of a report as it is a summary of information pertaining to the Resource Index. This information can be viewed from the Resource page.
      2. • Reporting on Identity Manager audit data:
         1. > Audit Reports
            1. It is based on events captured in the system audit log.
         2. > Usage Reports
      3. • Reporting on data extracted directly from resources:
         1. > Risk Analysis
         2. > Resource User Report
            1. List resources and which users have accounts on those reports.
         3. > Resource Group Report
            1. List Resource groups and which resources are part of those resource groups.
   3. Compliance Reports
      1. • Summary Reports ― Show which users have accounts on which resources
      2. • Account Index Reports:
         1. > Show which resource accounts are not owned by a user ]
         2. > Allow unassigned accounts to be linked to a user, disabled, or deleted.
      3. • Risk Analysis Reports ― Show accounts that are expired, inactive, never been used or do not require a password.
      4. • Administrator Reports ― Show which users in Identity Manager have rights to see data and control user access in Identity Manager.
   4. Auditing
      1. • Auditing records who did what, when, and to which Identity Manager objects.
      2. • Actions taken through Identity Manager are recorded in the Audit Log: Session, Workflow, Provisioner.
      3. • The Audit Log does not replace the audit functionality built into the native resources.
      4. • Custom Audit Log types and actions can be configured in the product.
4. Best Practices
   1. Achieving Compliance in IDM
      1. • Rename the Configurator/Administrator account and reset password to unknow value.
      2. • Limit the number of administrators who have control over the Top organization and have the ability to change Configurator's password. This will be audited.
      3. • Tie all administrator accounts to a real user account.
      4. • Execute Administrator Reports to verify that Identity Manager administrators have the correct scope and capabilities.
      5. • Configure secure communication for data transmission.
5. Password Management
6. Reconciliation
   1. IDM can be configured to detect
      1. New and deleted accounts
      2. Changes to account attribute values
      3. Accounts that are not associated with users (and correlate them if possible)
      4. Accounts that have been moved from one container on a resource to another container on a resource
   2. During reconciliation, all the resource account attributes are mapped into the global namespace
   3. Seed virtual Identity
      1. Account Index
      2. Primary Source
         1. Factors to select primary source
            1. Does the resource contain the universe of accounts?
            2. Is the data in the resource considered authoritative or it could it possibley incorrect be incorrect data?
            3. Is it a highly utilized resource?
            4. Does it contain enough information to build the identity?
            5. Does it contain a unique naming attribute?
            6. Can you correlate other accounts with the attributes contained in this resource?
      3. Tools for Loading Accounts
         1. Standard Tools
            1. Load from file
            2. Advantages
            3. Quickest loading process
            4. Easy to control which attributes are load
            5. Do not call any workflow
            6. Disadvantages
            7. Requires time to generate a CSV file from a resource
            8. Requires full reeconciliation before production
            9. Cannot be used to update accounts
            10. Load from resource
            11. Advantages
            12. Work with all resources
            13. Easier to configure than reconciliation
            14. Do not call any workflow
            15. Disadvantages
            16. Cannot pick and choose which resource accounts will be loaded
            17. Requires a full reconciliation before production
            18. Reconcile
            19. Advantages
            20. Can implement all aspects of reconciliation policy
            21. Using reconciliation up-front prevent last minute surprises
            22. Can be scheduled
            23. Disadvantages
            24. Cannot pick and choose which resource accounts will be loaded
            25. Can take a larege amount of time to load all accounts in large environments (more than 50,000 employees)
         2. Specialized Tools
            1. Identity console (cli)
            2. Extract/Load
            3. Import XML Objects
            4. Bulk Actions
            5. Advantages
            6. Allows you to add multiple accounts simultaneously to an Identity Manager User
            7. Can be scheduled
            8. Disadvantages
            9. Slower than loading from resource or reconciliation
            10. Cannot easily generate the CSV file from resources
            11. Requires detail knowledge of Identity Manager to make full use of these feature.
            12. Requires a full reconciliation before production
            13. Note
            14. Use it in production environments, but only very carefully
            15. One mistake in the bulk action can impact all user in the repository
            16. Active Sync
            17. Note
            18. If at all possible, avoid choosing Active Sync as the means to load account information. Active Sync is designed to detect changes, and as a result, initial loads are slow.
            19. Can be scheduled
            20. Import Exchange File
            21. End User Self Discovery
      4. Reconciliation
         1. Loading accouints from a primary resource
            1. Verify resource adapter configuration
            2. Configure account and password policies
            3. Account and Password Policies
            4. The default Lighthouse Account Policy uses other policies to specify what is considered a valid Identity Manager user name and passowrd.
            5. A default Identity manager user name adheres to the AccountId Policy
            6. The default password for a user adheres to the Password Policy
            7. Attempts to load resource accounts that do not follow these policies are rejected.
            8. You should either update the default policies or create your own before attempting a data load.
            9. Identity Manager Account Policy can generate AccountId and Password for initial user.
            10. Resource Account and Password Policies:
            11. Not used during Reconcile, Load From Resource, or Load From Resource.
            12. Only used during true resource provisioning processes.
            13. Create a load from for processing data.
            14. Load Form
            15. The Load Form maps data from resource account to Identity Manager users
            16. The Load form configures User objects:
            17. Organization
            18. Roles
            19. Policies
            20. Capabilities
            21. When creating a Load Form:
            22. Starts with an emty form - do not use existing forms as templates
            23. Add only attributes needed for loading
            24. Crate a proxy account in Identity Manager for loading
            25. Proxy Admin Account
            26. A service account (not assigned to a real person)
            27. Has Account Administrator Privileges and controls the top organization.
            28. Must have sufficient capabilitites to create and view users
            29. Has a load form assigned to the account that is applicable in the following situations:
            30. Reconcile and Bulk Actions - Only use the proxy load form
            31. Load from resource, Load from file and Active Sync - Use both the input form and the proxy load from
            32. Associate load form with proxy account.
            33. Configure extended attributes to store correlation keys.
            34. Adding extended attributes
            35. Edit UserUIConfig
            36. Add the attribute QueryableAttrName object for basic searching
            37. Add the attribute to the RepoIndex object for fast database-index searching (maximu of five allowed)
            38. Implement correlation and confirmation rules.
            39. Correlation and Confirmation Rules
            40. IDM uses correlation and confirmation rules to link accounts to other resources:
            41. Correlation rules
            42. Look for IDM users that might own an account.
            43. Return a list of users that match the criteria defined in the correlation rule.
            44. Are a brief, fast search.
            45. Only look at data contained in the IDM repository; they do not look at view data.
            46. To achieve optimum performance, correlation rule searches should be performed on attributes that have indexed in the Repository.
            47. Confirmation rules
            48. Validate users returned by a correlation rule to determine whether the user actually does own the account.
            49. Return true or false values
            50. Uses all data contained in the view to find potential matches.
            51. Are exhaustive; more time consuming verification. (slower)
         2. Definition
            1. Compares the contents of the Account Index to what each resource currently contains
            2. During reconciliation, all resource account atributes are mapped into the global namespace.
            3. If these attributes match an IDM user attribute, such a firstname, lastname or employeeId, then the attribute is set on the IDM user during creates ONLY!
            4. All attribute that do not directly match IDM attributes are ignored.
            5. Reconciliation only processes the Proxy Admin Form during creation of new users and only pushes global attributes during creation of new users.
            6. Can detect the following:
            7. New and deleted accounts
            8. Changes to account attribute values
            9. Accounts that are not associated with users.
            10. An account that has been moved from one container on a resource to another container on a resource.
            11. Can run a workflow in response to each situation detected.
            12. types
            13. Full Reconciliation
            14. A comprehensive evaluation of IDM users and all resource accounts
            15. Is typically a first time account seeding step
            16. Is used to refresh the system after downtime.
            17. Does not trust Account Index; can fix problems with both users and Account Index.
            18. An IDM user can claim a resource by:
            19. Having a role that implies the resource.
            20. Having a direct resource assignment
            21. Referring to an account on the resource.
            22. Phases:
            23. Pending
            24. Examining Identity Manager
            25. Indexing Users
            26. Examining resource
            27. Reconciling accounts
            28. Performing responses
            29. Posible Finalization Status:
            30. unknown
            31. disabled
            32. failed
            33. success
            34. completed with errors
            35. Full Reconcile Steps
            36. Launch pre-reconciliation workflow
            37. Find all users with resource already assigned
            38. Fetch last known state from Account Index.
            39. List all accounts from resource.
            40. Detect Native changes for all accounts
            41. Perform per account steps.
            42. Launch post-reconciliation workflow.
            43. Incremental
            44. Trust the Account Index and only processes accounts that have been added or deleted.
            45. Is much faster than Full Reconciliation, because it processes add/deletes ONLY
            46. Must still list all accounts on the resource, which can potentially be time consuming.
            47. Is run daily (or hourly) to refresh the account Index.
            48. Incremental Reconcile Steps
            49. Launch pre-reconciliation workflow
            50. List all accounts from resource
            51. Compare to the Account Index
            52. Detect native changes for all accounts.
            53. Perform per account steps for new or deleted accounts only.
            54. Launch post-reconciliation workflow
            55. Reconciliation Policies
            56. Allow you to establish a set of responses, by resource, for each reconciliation task.
            57. Allow you to specify the following:
            58. Server node used to run reconciliation.
            59. Mode of reconciliation: full or incremental.
            60. Reconciliation Schedule
            61. Responses for each situation encountered during reconciliation
            62. Whether to detect changes made natively to account attributes.
            63. Scope of Recon Policies:
            64. Recon Policies can be applied globally, for a resource type, or for a specific resource.
            65. Parameters are inherited from the parent unless they are overridden at lower levels.
            66. Global settings are typically used to specify the reconcile server and proxy administrator account.
            67. Resource type settings are typically used:
            68. When many resources are of the same type.
            69. To ensure consistency of policy settings
            70. Specific resource settings provide granularity for an individual resource.
            71. Attribute level reconciliation
            72. • Reconciliation can watch and detect attribute changes on a resource
            73. • Watched attributes must be:
            74. > Identified in the reconciliation policy
            75. > Stored in the Account Index for each account
            76. • When a change is detected, workflow launches to take appropriate action
            77. • Implications:
            78. > Increases reconciliation processing time and storage requirements
            79. > Takes as long for an incremental as for a full reconcile for IDM repository.
            80. Situations Options and Responses
            81. • Reconciliation determines the current state (situation) for each account processed based on correlation rules and the last know state.
            82. • A specified action (response) can be configured for each state.
            83. • Situations and responses should be well understood before configuring in production.
            84. • Leaving all responses set to Do Nothing updates the Account Index only (default) .
            85. Different Situations
            86. Confirmed
            87. What it means
            88. The user indicates that the resource account exists, and the resource account is found on the resource.
            89. Possible Responses
            90. Do nothing
            91. Deleted
            92. What it means
            93. The IDM user says the account exists, but the resource says that the account does not exists.
            94. ResourceInfo created='true'
            95. Possible Responses
            96. Unlink the resource account from the IDM user.
            97. Provision a new resource account for the IDM user.
            98. Found
            99. What it means
            100. The user account reference does not specify that the account has been created, and the resource indicates that the account does exist.
            101. ResourceInfo created='false'
            102. Possible Responses
            103. Link the found resource account to the matching IDM user .
            104. Missing
            105. What it means
            106. The user's accounr reference does not specify that the account has been created, and the resource indicates that the account does not exist.
            107. ResourceInfo created='false'
            108. Possible Responses
            109. Unlink the resource account from the Identity Manager user
            110. Provision a new resource account for the Identity Manager User
            111. Collision
            112. What it means
            113. Two or more IDM users claim the same resource account
            114. Possible Responses
            115. No responses
            116. Unassigned
            117. What it means
            118. The resource account matches exactly one IDM user, but that user does not say anything about the account.
            119. Possible Responses
            120. Link the resource account to the IDM user.
            121. Delete the resource account.
            122. Disable the resource account.
            123. Unmatched
            124. What it means
            125. The resource account matches no IDM user.
            126. Possible Responses
            127. Create a new IDM user based on the resource account.
            128. Delete the resource account.
            129. Disable the resource account.
            130. Disputed
            131. What it means
            132. The resource account matches more than one IDM user.
            133. Possible Responses
            134. Delete all the resource account
            135. Disable the resource account
            136. Typical Scenarios
            137. • Initial load:
            138. > UNMATCHED – Create a new user
            139. • Account correlation:
            140. > UNMATCHED – Create a new user
            141. > UNASSIGNED – Link resource account to user
            142. • Steady State, continue using native tools:
            143. > UNMATCHED – Create a new user
            144. > UNASSIGNED – Link resource account to user
            145. > MISSING, DELETED – Unlink resource account
            146. • Steady State, provisioning from Identity Manager:
            147. > DELETED – Provision new account on resource
            148. > FOUND – Link resource account to user
            149. > MISSING – Provision new account on resource (or do nothing)
            150. > UNASSIGNED, UNMATCHED – Disable or delete resource account
            151. Reconcile Scheduling
            152. • Separate schedules are maintained for full and incremental reconciliation.
            153. • Each resource has a TaskSchedule object that can be controlled externally.
            154. • Reconciliation only allows three resources to be reconciled at one time by default.
            155. Scheduling aditional reconcile tasks results in the later tasks wainting until the earlier tasks complete.
            156. • The Tasks page in the Administrative Interface should show an entry for each resource scheduled.
7. Workflows
   1. Definition
      1. Workflow is a logical, repeatable process during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.
      2. A participant can be a person, a machine, or both.
   2. Workflow Processing
      1. • Workflow operates as a specialized form of an executing task.
      2. • It walks through a defined set of activities in a task using a path defined by transitions.
      3. • Actions defined within those activities are executed by the Workflow Task as the work accomplished in a task.
   3. Workflow Execution Types
      1. WorkflowExecutionTypes.jpeg
   4. Workflow Components
      1. • Workflow Executor – Specialized task executed by the Scheduler to evaluate TaskInstance objects
      2. • Task Definitions (TaskDefinition object):
         1. > Describe activities that are connected through transitions
         2. > Constructed as XML Objects in Identity Manager
      3. • Task Instances (TaskInstance objects):
         1. > Instantiate a task definition that is executed by the Workflow Executor
         2. > Persist the state of the task variables and current place in execution of task definition
   5. Workflow Activity
      1. • An activity is a single step in the workflow process.
      2. • Each activity can contain multiple components, including transitions, variables, and actions.
   6. Workflow Actions
      1. • Can be simple expression evaluations
      2. • Can be complex Java class invocations (workflow applications)
      3. • Support iterating over lists, allowing for multiple, parallel executions of the action
      4. • Include the following:
         1. > Setting variables
         2. > Providing approvals
         3. > Invoking custom classes
         4. > Calling external scripts or programs
         5. > Invoking Repository API
   7. Repository APIs
      1. • com.waveset.object.LighthouseContext
         1. > Contains methods for manipulating objects in the Repository and accessing the object cache
         2. > Enforces the authorization model
         3. > Accesses context information within forms and rules with <ref>context</ref>
      2. • com.waveset.provision.WorkflowServices
         1. > Provides provisioning functions such as create, update, delete, and associated error handling
         2. > Contains utilities to send notifications and obtain a list of approvers
8. ActiveSync
   1. Steps to configure active synchronization
      1. x
      2. > Correlation and confirmation rules
      3. > Creating an Empty Form and Proxy Administrator
      4. > Creating a New Resource
      5. > Schema Map for a Resource
      6. > Configuring the Synchronization Policy
      7. > Configuring Identity Attributes
      8. > Starting Synchronization
9. Phased Implementation Approach
   1. Phase 1 - Regulatory Compliance and Self-Service
      1. • Meet regulatory compliance guidelines
      2. • Provide user self-service password management
      3. • Update the interface for corporate branding requirements
      4. Deployment Roadmap
         1. Connect to Resources
         2. Create Administrators
         3. Seed Identity Manager Users
         4. Configure Audit Reports
         5. Enforce corporate password policies
         6. Enable pass-through authentication
         7. Customize Identity Manager interfaces
         8. Customize administrative interface
   2. Phase 2 - Role Based Provisioning
      1. • Implement a delegate administration model
      2. • Streamline process for project managers to manage project-based access control
      3. Deployment Roadmap
         1. Create Project-based roles
         2. Create a Delegated Administration Environment
         3. Create Custom forms
         4. Create Custom Workflos
   3. Phase 3 - Identity Sinchronization
      1. • Synchronize Active Directory with HR and other databases
      2. • Construct a corporate LDAP directory for existing users
      3. Deployment sub-phases
   4. Phase 4 - Self-Registration
      1. • Implement a contractor self-registration system
      2. • Use custom forms for self-registration and role assignments
      3. • Use custom workflow for approvals
      4. Deployment sub-phases
   5. Implementation approach sumary
      1. • Configure a resource adapter to connect to and examine each system
      2. • Define administrative users for executing reconciliation and generating regulatory reports
      3. • Build a virtual identity for every employee:
         1. > Seed virtual identities from an authoritative resource
         2. > Correlate other resource accounts to virtual identities
         3. > Schedule updates to the virtual identity store
      4. • Build example reports for regulatory compliance enforcement
10. Resource Adapters
    1. Types
       1. Mainframe security managers
       2. Databases
       3. Directory servers
       4. Operating Systems
       5. Enterprise Resource Planning (ERP) Systems
       6. Messaging Platform
    2. Uses
       1. • Create, update, and delete objects on a resource during workflow processing
       2. • Retrieve data attributes or objects on resources
       3. • Fetch single accounts or list all accounts during reconciliation
       4. • Validate user credentials when implementing pass-through authentication
       5. • Process change events for accounts
11. Questions
    1. How workflow can be launched using Simple Object Access Protocol (SOAP) to execute provisioning tasks?
    2. SPML 1.0 vs SPML v 2.0
    3. IDM vs IDM SPE
12. Tips
    1. SYNC_ResourceName
       1. Is a generic object type that keeps the last successful event processed for the ActiveSync
13. Generic Objects, Path Expresions and Views
    1. Generic Objects
       1. • Represent complex hierarchical objects (maps of lists of maps) and allow easy navigation of the data structure
       2. • Are typically used to represent views and are simple collections of name/value pairs:
          1. > Generic Objects are essentially a Java class that implements the Map Interface.
          2. > You can access these attributes externally through path expressions.
       3. • Are the foundation for manipulating the hierarchical view through simple HTTP request data flat list of attributes)
       4. • Are supported as a data type using the <Object> tag
    2. Path Expressions
       1. • Is a string interpreted at runtime by the GenericObject class.
       2. • Is used to retrieve or assign the value of an attribute contained in an object hierarchy.
       3. • Consists of periods and brackets to represent objects and attributes.
       4. • Is used as the value of the name attribute in form fields when customizing a form:
          1. <Field name='user.waveset.roles'>
    3. Views
       1. • Generic Objects that consist of attributes assembled from one or more objects.
       2. • Similar to database views:
          1. > Abstracts a complex join of several tables
          2. > Provides a single, readable (and writable) interface
       3. • Used to display and edit a user's identity
       4. • Transient – Are not stored in the Repository
       5. • Used primarily in forms and workflows
       6. Types
          1. • Several types of views are available:
             1. > Data contained in the view can be different.
             2. > Structures can be different.
          2. • Examples of views are:
          3. RenameUser - Rename identity
          4. Enable/Disable - Enable/disable accounts
          5. Deprovision - Delete accounts
          6. Password - Change password on one or more accounts
          7. ReconcileStatus - Fetch status from last reconciliation run
          8. WorkItem - Provide object model for manual interaction in workflow
       7. The User View
          1. • Consolidates all identity information for a user
          2. • Consists of attributes that are:
             1. > Stored in Identity Manager
             2. > Read from resource accounts
          3. • Is used when creating or editing users in Identity Manager
       8. Namespaces
          1. accountInfo
             1. Resource and account information.
          2. accounts
             1. Values of attributes fetched from resources.
          3. display
             1. Runtime state of the interface
          4. global
             1. Attributes synchronized across all resources.
          5. password
             1. Attribute values specific to user's password, password expiration and target system.
          6. waveset
             1. Information stored in the repository.
    4. Forms
       1. • Forms are Generic Object editors.
       2. • Forms are used to display and edit view data.
       3. • Forms are the portions of the Identity Manager interface that contain data entry areas.
       4. • The <Form> XML object is comprised of <Field> elements that map to attributes in the Generic Object.
          1. > The field name is a view path expression.
          2. > The field name defines the graphical display of a view attribute, an application of business logic (XPRESS), or both.
       5. Forms control the following:
          1. • Layout and display characteristics of the page
          2. • Data that is used on the page
          3. • Data that is coming into the system
          4. • Identity Manager background processing
       6. Form Fields
          1. • The form body contains field elements that define how each element of the web page appears and behaves.
          2. • Each field can contain other fields, each with its own display component.
          3. • Form fields comprise several parts, which are encapsulated by the <Field> tag set:
             1. > Value expressions
             2. > HTML display components
             3. > Disable expressions
             4. > Validation expressions
       7. Form Field Elements
          1. Default
          2. Derivation
          3. Expansion
          4. Validation
          5. Disable
14. SPML
    1. Configurations Objects
       1. • Configuration:SPML
       2. • Configuration:User Extended Attributes
       3. • Configuration:UserUIConfig
       4. • TaskDefinition:SPMLRequest
       5. • SPML Forms
    2. How Request are Processed
       1. addRequest
          1. 1. An SPML <addRequest> message is received. The request must include a value for the object class attribute.
          2. 2. The server examines the Configuration:SPML object to find the definition for the class. From the class definition, it obtains the associated view type and form name.
          3. 3. The server calls the Session.createView method to construct a new view for that type.
          4. 4. The attributes included in the request are processed by the class form. The results of the ,Expansion> expressions are assimilated into the view.
          5. 5. The view is checked in.
       2. modifyRequest
          1. 1. An SPML <modifyRequest> message is received. The request can include an optional objectclass attribute. The request must contain an identifier for an existing object. The identifier must include both the repository type and the object name.
          2. 2. The server calls Session.checkoutView for the existing object.
          3. 3. The server examines the Configuration:SPML object to find the definition for the class. If an objectclass attribute was passed in the request, that value determines the class. Otherwise, the class marked as the default class for the repository type is used.
          4. 4. The attributes included in the request are processed by the form that is specified by the class definition. The results of the <Expansion> expressions are assimilated into the view.
          5. 5. The view is checked in.
       3. searchRequest
          1. 1. An SPML <searchRequest> message is received. The request can include an optional objectclass attribute.
          2. 2. The server examines the Configuration:SPML object to find the definition for the class. If an objectclass attribute was passed in the request, that determines the class. Otherwise, the class marked as the default class for the User type is used.
          3. 3. If the request includes a filter, it is converted to a list of AttributeCondition objects. Because the filter terms are written using the external names, the class form is consulted to convert these into the names of queryable attributes on the repository type.
          4. 4. The server calls the Session.listObjects method with the repository type and optional conditions.
          5. 5. The server builds the search response by iterating over each row of the listObjects call applying the following steps.
          6. 6. If no list of return attributes is specified in the search, only the summary attributes defined for the repository type are returned. The class form is used to convert the internal summary attribute names into the external names.
          7. 7. If a list of return attributes is specified, and these all correspond to summary attributes, the summary attribute values are returned. The form is again used to convert internal to external names.
          8. 8. If a return attribute is specified that is not a summary attribute, the server calls Session.getView on this object to materialize the view. The view is processed with the class form and the results of the <Derivation> expressions are captured and returned as the results for that row.