Controlling Repository Access

The repository administrator is responsible for controlling access to the documents stored in the repository by creating users and groups and assigning them rights, permissions, and profiles. The administrator may connect PowerDesigner to an LDAP server for authentication, an SMTP server for automating notifications, and specify a policy to control the strength and duration of passwords.

1. [optional] Connect the repository to an LDAP server to manage user access (see Connecting to an LDAP Server for User Authentication).
2. [recommended] Connect PowerDesigner to an SMTP server to enable the automatic sending of emails for passwords, changelist submissions, and other notifications (see Connecting to an SMTP Server for Notifications).
3. If some or all your users will not be managed by LDAP, specify an appropriate password policy (see Defining a Password Policy).
4. Create high-level functional groups (see Creating Repository Groups) to organize users by type and assign appropriate rights to them to govern general actions that they can perform in the repository (see Granting Rights to Users and Groups).
   For example:

   Groups	Rights
   Administrators	Connect, Manage All Documents, Manage Users, Manage Repository
   Senior Architects	Connect, Freeze Versions, Lock Versions, Manage Branches, Manage Configurations
   Architects	Connect, Freeze Versions, Lock Versions
   Business Analysts	Connect, Freeze Versions, Lock Versions
   Stakeholders	Connect (to provide read-only access via the PowerDesigner Portal).

   Note: There is no requirement to create groups - you can assign rights and permissions to individual users - but we recommend that in all but the smallest deployments, you do create groups to simplify the process.
5. [optional] Use the supplied profiles or develop others and apply them to your groups as necessary to filter the PowerDesigner interface to hide or render read-only types of models, objects, and properties, and to specify defaults for interface elements, options and preferences for different kinds of users (see Using Profiles to Control the PowerDesigner Interface).
   In our example, business analysts need only contribute to requirement models, enterprise architecture models, and conceptual data models and all other types of models are hidden from them. We could imagine dividing the Architects group into subgroups such as enterprise architect and information architect and hiding or rendering read-only models that do not concern them.
6. Create an appropriate folder structure in the repository (see Repository Folders) to enable you to group documents by project or in any other appropriate way, and to simplify the granting of permissions.
   In the example, the team will use the library folder to share reference models and other documents, and to push targets, extensions, and other resource files to users (see Deploying an Enterprise Library). In addition, two modeling projects are proposed, and all the documents related to them will be kept in the two top-level folders.
7. Determine your review policy either at a global or project by project level. PowerDesigner supports the following kinds of policy:
   • Simple review - Change lists submitted by users with the Submit permission are reviewed by a single user with the Write or Full permission.
   • Peer review - Users with the Write or Full permission voluntarily submit change lists for review.
   • Direct check in - The Submit permission and change lists are not used, and users all check in changes without review.
8. Create development groups and implement your review policies by assigning appropriate permissions to control what actions users and groups can perform on particular repository documents and folders such as your library, glossary model, and modeling projects.
   In the example, we propose:

   • A Compliance Committee who can modify the reference models and shared resource files contained in the library and can submit changelists for inclusion in the glossary model.
   • A Terminology Committee who can modify the glossary model.
   • For each project, lead architects are able to check in changes to the project (and submit changelists for inclusion in the glossary), and regular architects can submit changelists to the project.
   • A cross-project stakeholder groups with read-only access (though we could imagine sub-folders within each project for which these users would have write or submit permission for storing their own documents).

   Group	Library	Glossary Model	Project A	Project B
   Administrators	Full	Full	Full	Full
   Compliance Committee	Write	Submit	Read	Read
   Terminology Committee	Read	Write	Read	Read
   Project A Leads	Submit	Submit	Write	Read
   Project A Team	Read	Read	Submit	Read
   Project B Leads	Submit	Submit	Read	Write
   Project B Team	Read	Read	Read	Submit
   Business Stakeholders	Read	Read	Read	Read

9. Create as many users as necessary either manually (see Creating Repository Users) or via LDAP (see Creating Repository Users Managed by LDAP) and assign them to appropriate groups (see Adding Users and Groups to a Group) according to their roles and project responsibilities.
   There is no limit to the number of groups to which a user or group can be assigned, and users benefit from the cumulative total of all the rights and permissions they receive. In our example, if a business stakeholder is also a member of the Terminology Committee group, then she will have Write permission on the glossary model.

• Connecting to an LDAP Server for User Authentication
  A repository administrator can delegate the authentication of repository users to an LDAP server. PowerDesigner supports authentication via Active Directory and a number of other LDAP implementations. You can optionally allow automatic creation of repository accounts when an LDAP user connects to the repository for the first time.
• Connecting to an SMTP Server for Notifications
  The repository administrator can automate the sending of emails for passwords, changelist submissions, and other notifications to users by specifying an SMTP server for PowerDesigner to use.
• Defining a Password Policy
  The repository administrator is responsible for defining a password policy to ensure that passwords are sufficiently secure and are changed at appropriate intervals. The password policy governs only users who are not managed by LDAP.
• Creating Repository Users
  The repository administrator is responsible for creating user accounts to enable users to connect to the repository and access the content that they need.
• Creating Repository Users Managed by LDAP
  If you have not selected the Auto-create user accounts in repository option, you must create repository accounts for each user that you want to be able to connect. Even if you select this option, we recommend that you create appropriate user accounts in advance in order to grant appropriate rights and permissions on your various repository folders and documents.
• Creating Repository Groups
  The repository administrator is responsible for creating groups of users in the repository. Users are added to groups in order to simplify the granting of rights and permissions and the use of profiles. You can create hierarchies of groups. For example, you could insert the Designers, Quality Assurance, and Documentation groups into the R&D group, to which you assign permissions to documents that all these groups must use.
• Granting Rights to Users and Groups
  A new user has only the Connect right assigned by default and belongs only to the PUBLIC group, which has no rights. In order for the user to be able to do anything, the repository administrator must grant rights to her either directly or by adding her to other groups.
• Granting Access Permissions on Repository Items
  The repository administrator or a user with Full permission on a document or folder can grant permissions on it from the Permissions tab of its repository property sheet. You can grant permissions on the repository root, folders, PowerDesigner models and model packages, and external application files, but not on individual model diagrams or objects.
• Unblocking Blocked Users
  The repository administrator or a user with the Manage Users right can unblock users blocked for password policy violations.
• Deactivating Users
  The repository administrator or a user with the Manage Users right can deactivate users. An inactive user cannot connect to the repository, but the information about his checkins and other repository actions remains available to other users. An inactive user can be reactivated at any time.
• Auditing Repository Activities
  Users with the Manage All Documents right can use the List of Activities to audit operations performed on repository documents, analyze user behavior patterns, and highlight activity sequences. Activities are actions that modify repository documents, such as check in, freezing, and deleting.
• Querying the Repository Using SQL
  Administrators can run basic SQL SELECT queries against the repository through the Execute Query window. For more complex queries, you should use your DBMS query editor.
• Obtaining Emergency Access to the Repository
  In the event that no administrator is able to log in to a running repository, it is possible to create an emergency administrator account to regain access.