9 0 UG:Create Security
Only registered and licensed users can access the Project.net application by logging in. Only people who have been added (invited) to the team directory of a workspace are allowed to enter that space and access the information stored there.
Within each workspace, the Space Administrator can set general access permissions (Module Permissions) for each module. The Space Administrator can also set New Object Permissions for the various object types in the workspace. New Object Permissions determine the access rules that are applied to objects by default when objects are created by a user. Individual Object Permissions can be changed by the person who created the object or by the Space Administrator after the object has been created.
The Project.net application offers several types of security:
- password-based authentication (login) using the built-in authentication or an external LDAP server
- role-based security settings
- user-based access controls on information
- 128-bit SSL encryption between the client and server (optional)
Most Project.net users will only use the Security action in the Action Toolbox to view and change Object Permissions on a specific object. By default, users can only view and change these permissions if they created the objects.
Each workspace has one or more "Space Administrators". The Space Administrators are responsible for defining roles, adding people to roles and setting access permissions for the workspace. This is done from workspace directory module and the Setup link in the workspace.
 Space Administrator
The Space Administrator is a special system-defined role in each workspace. The Space Administrator has full access to the entire workspace and controls permissions to all modules and objects within the workspace. The Space Administrator has the ability to control security and security permission throughout the workspace.
Security settings allow the space administrator to control which roles or individual team members can view, modify, create, or delete items in a project. The space administrator also controls who has the right to modify permissions for each module or object in the project, and can apply security at the Module level, as well as at the New Object level.
Before inviting users to a project, the Space Administrator should review and edit the Module Permissions and New Object Permissions for all roles in the project.
Recommendation: When setting up a new project, create roles (i.e., vendors, customers) and assign minimal permissions to the roles BEFORE inviting people to the project. This allows people to be assigned to their roles (and respective security settings) at the same time they are invited to the project. Change a role or individual’s settings, as needed, to customize the security settings further. (NOTE: All invitees are automatically assigned to the Team Member role.)
 Team Member
When participants (also known as “users” or “team members”) are initially invited to a Project.net project or business workspace, they automatically become members of the ‘Team Members’ role. All team members of a workspace are members of this role and cannot be removed from the Team Members role unless they are removed from the workspace. For this reason, it is important to limit the permissions for the Team Member role, especially if outside companies are involved in the project.
NOTE: Any team member who creates an object automatically has the right to modify all permissions for that object
 Individual vs. Role-based Permissions
The Space Administrator can apply access permissions to specific individuals as well as roles. Security is one of the most important reasons that Project.net team members should be divided into roles. These roles allow Space Administrators to easily set and change permissions for groups of people in one step.
Role-based permissions are additive. If a participant belongs to two roles, and one role has permission to view and modify a specific object, and the second role has permission only to view, then that participant will have permission to both view and modify.
Personal permissions override all Role-based permissions. If a person is granted permissions to a specific object (personal permission), all role-based permissions will be ignored for that user and object. For example, if the Team Member role allows view, modify and delete permissions to a specific document, but the user has a personal permission allowing only view, the user will not be able to modify or delete the document, only view it.
The personal permission is useful for granting extra permissions or removing permissions for a single user where creating a special group would be cumbersome. However, personal permissions are harder for the administrator to keep track of and manage. It is important to try to use role-based permissions instead of personal permissions whenever possible.
 Module Permissions
Object and Module level permissions and security can be defined to every Person or Role in the Project. This can be accessed by choosing the [Security] option under the Setup module for the project or Business.
Module permissions apply to an entire module such as Documents, Forms, Calendar, etc. They determine the Role or Person’s permission to access each module and access the objects within a module. If users do not have permission to view a module (through a role or personal permission), they will not be able to access that module or any of the items in that module. The following are the modules that permissions can be applied to:
- Discussion Forums
- Document Management
- Form Databases
- Project Process
- Project Schedule
- Project Space
- Workspace Templates
NOTE: If participants create objects within a module and those participants later have view access revoked for that module, the participants will still be able to access the objects they created in that module. This is because team members are granted full access to any object that they have created.
Choosing the Module Permissions tab under the Business or Project security lists the default permissions defined for every member or role in the Project or Business. Module permissions are composed of several actions: view, modify, create, delete, and modify permission:
- View – The user can access a module and view the module’s contents. The user access to module contents may be further limited by the object permissions on specific information within the module. If the user does not have view permission to the module, he will not be able to enter the module.
- Modify -- The user has the ability to modify properties of a module (if any).
- Create – The user has the ability to create new items within the module.
- Delete – The user has the ability to delete items within the module. This permission may be overridden by specific object permissions.
- Modify Permission – the user may modify the security permission for this module.
For more information on Module Permissions, refer Business/Project Module Permissions
 Object Permissions
Security access and permissions to a person or role can also be based on the objects in the application. For example, a role or user may have access to the entire Document Vault except for a folder and its documents by setting Security on that folder. In general, options that apply to individual objects are:
- View – The user can view (read-only) the object.
- Modify -- The user has permission to modify the object.
- Create – The user has permission to create new items of this object type.
- Delete – The user has permission to delete the object.
- Modify Permission – the user may modify the security permission for this object.
For more information on Object Permissions, refer Business/Project Object Permissions
 New Object Permissions
New Object Permissions determine the default access permissions that will be assigned to each new object created within a workspace. It would be tedious for a user to manually apply permissions to every object that is created; the New Object Permissions allow the Space Administrator to set reasonable default permissions for each type of object in a workspace. A user can then change the permissions on a newly created object if non-typical permissions are required. For example, the new object permissions could be setup so that the Customer role has view-access to all documents and the Team Member role has view, modify, and remove permissions.
The New Object Permissions are set in the Setup Security area. The following are objects that can be created and security can be applied to:
- Configuration Space
- Deliverable: A Phase Deliverable
- Discussion Group
- Document Folder
- Calendar Event
- Form Type
- Form instance data (all versions)
- Gate: A Phase Gate
- Security Group
- Calendar Meeting
- Phase: A Process Phase
- Process: A Project Process
- Schedule Task or Milestone
 Module Permissions Override Object Permissions
Module permissions override object permissions. If the Document Management Module View permission is deactivated for a person or role, then the person/role will not be able to view, modify, create, delete, or modify permissions of the Document Management Module ("Document Vault"). The Modify permission for the Document Vault means that the user can check out documents and change document properties. The Create permission for a Document Vault means that the user can add new documents, create folders, etc.
When the View permission for a module is removed, the person/role will not be able to view, modify, create, delete, or modify the security of any objects (document folders or documents) associated with that module.
Exception: The user who originally uploaded a document will still be able to access this document (from links to other objects or from the “recently modified documents” channel) after this new security setting takes effect. The administrator can remove personal document permissions from the user by clicking the specific document and altering the security settings, but this action would have to be done for each document the user created before the new settings took effect.
 Security can be modified in three ways
- Space Administrator clicking Setup in the navigation bar to modify Module permissions.
- Space Administrator clicking Setup in the navigation bar to modify New Object permissions.
- Space Administrator or Team Member clicking the Security action (when it is active) in the Toolbox to set permissions on individual objects such as forms or documents.
 Active - deactivate all permissions simultaneously
It’s possible to deactivate all Module Permissions or New Object Permissions at the same time for a role or person. This is achieved by de-selecting the Permissions Active check box.
- When the Permissions Active check box is checked (default setting), the permitted actions are available to be assigned for the current person or role.
- When the Permissions Active check box is blank all permitted actions are simultaneously deactivated for that role or person. (This is not readily apparent since the check box settings under the Permitted Actions columns will not change.)
 To Simultaneously Deactivate All Permissions
1. Each tab in the Security Manager has a Permissions Active check box. This allows the space administrator to remove permissions to all modules or all new objects from either a Person or a Role. To deactivate all permissions for a Person or a Role, select the Person/Role from the Person/Role drop-down list, and then deselect the Permissions Active check box.
2. Click the Submit button to save your changes.
 More Help
It is our belief that Project.net users know what they want in their Project.net documentation, therefore, we encourage you to edit this Wiki page and contribute your corrections and additions. If you read something that is not clear make a note of it on the Discussion tab.