chap-best-pract.xml revision 7d19a158b53f47b175ba1e6aad07c79365847ae6
<?xml version="1.0" encoding="UTF-8"?>
<!--
! CCPL HEADER START
!
! This work is licensed under the Creative Commons
! Attribution-NonCommercial-NoDerivs 3.0 Unported License.
! To view a copy of this license, visit
! http://creativecommons.org/licenses/by-nc-nd/3.0/
! or send a letter to Creative Commons, 444 Castro Street,
! Suite 900, Mountain View, California, 94041, USA.
!
! You can also obtain a copy of the license at
! legal/CC-BY-NC-ND.txt.
! See the License for the specific language governing permissions
! and limitations under the License.
!
! If applicable, add the following below this CCPL HEADER, with the fields
! enclosed by brackets "[]" replaced with your own identifying information:
! Portions Copyright [yyyy] [name of copyright owner]
!
! CCPL HEADER END
!
! Copyright 2011 ForgeRock AS
!
-->
<chapter xml:id='chap-best-pract'
xmlns='http://docbook.org/ns/docbook'
version='5.0' xml:lang='en'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='http://docbook.org/ns/docbook http://docbook.org/xml/5.0/xsd/docbook.xsd'
xmlns:xlink='http://www.w3.org/1999/xlink'
xmlns:xinclude='http://www.w3.org/2001/XInclude'>
<title>OpenIDM Project Best Practice</title>
<section xml:id="immplementation-phase">
<title>Implementation Phases</title>
<para>Any Identity Management project whether using OpenIDM and/or other technologies should follow a set of well defined phases, where each phase discretely defines deliverables and takes the project from initiation to finally going live with a tested solution.</para>
<section><title>Initiation</title>
<para>This is the projects initiation phase where normally aims at identifying and gathering project background, requirements and goals at a high level. The deliverable of this step is to provide a Statement of Work or mission statement.</para>
</section>
<section><title>Definition</title>
<para>The definition phase, is where more detailed information is gathered such as existing systems, how to integrate, describing account schemas, procedures and other relevant information that might be of use deploying OpenIDM. The deliveryable of this phase is one or more documents defining the project from a detailed requirements point of view. This may include project definition, describing the business case, a fine grained and detailed requirements documentation, individual use-cases that must be solved and functional specification.</para>
<para>Here is an overview of typical aspects that the Definition Phase should try to capture, but is not limited to the topics outlined:</para>
<section><title>User Administration and Management</title>
<para>The procedures for managing users and accounts, who manages users, how does the processes look like (joiners, movers and leavers) and what is required of OpenIDM for managing users.</para>
</section>
<section><title>Password Management and Password Synchronization</title>
<para>The procedures for managing account passwords, password policies, who manages passwords, and what is required of OpenIDM to manage passwords.</para>
</section>
<section><title>Security Policy</title>
<para>What the corporate security policy defines for users, accounts, passwords, and access control.</para>
</section>
<section><title>Target Systems</title>
<para>The target systems or resources which OpenIDM should integrate with. Information such as schema, attribute mappings and attribute transformation flow, credentials and other integration specific information should be captured.</para>
</section>
<section><title>Entitlement Management</title>
<para>The procedures to manage user access to resources, individual entitlements, grouping provisioning activities in to encapsulated concepts such as roles, groups etc.</para>
</section>
<section><title>Synchronization and Data Flow</title>
<para>Outline in detail how identity information should flow from authoritative source(s) to target systems with necessary attribute transformations. </para>
</section>
<section><title>Interfaces</title>
<para>Define how to secure the various interfaces, REST, User Interface and File based as well as applicable communication protocols involved.</para>
</section>
<section><title>Auditing and Reporting</title>
<para>The procedures for auditing and reporting. Who are responsible for auditing and reporting and what information must be aggregated and reported upon? Are there any available reporting engine that should be leverage or does this needs to be provided?</para>
</section>
<section><title>Technical Requirements</title>
<para>The other technical requirements for the OpenIDM solution such as how to maintain the solution in terms of monitoring, patch management, availability, backup, restore and recovery process. This includes any other components leveraged such as off-shored ConnectorServer and plug-ins for password synchronization on Active Directory and/or OpenDJ.</para>
</section>
</section>
<section><title>Design</title>
<para>The design phase aims at designing the solution based on OpenIDM and other components. The deliverables for this phase is the architecture and design document and also define success criteria and a detailed description and test cases verifying project goals have been met.</para>
</section>
<section><title>Build</title>
<para>The build phase is where the solution is built to meet the requirements and tested prior to moving the solution into production.</para>
</section>
<section><title>Production</title>
<para>The production phase is where the solution is deployed into production and where an application steady state is reached to which maintenance routines and procedure is applied.</para>
</section>
</section>
</chapter>