Introduction #
Deepfactor allows admins to structure their users into multiple teams within their account. The following diagram shows the relation between teams and users using the example of a sample Acme organization.
Please note that
- A user can be part of multiple teams and have different roles per team. Ex. John is a developer in the API service team and a viewer in the product service team.
- It is possible for a user to not be a part of any team. In such a case, the user can login to the Deepfactor account but will not be able to view/scan/run any applications with Deepfactor until the admin adds the user to a team. Ex. Elle is not part of any team.
- A default team is created in every account and all existing users/applications are added to the default team. Admins who do not want to create multiple teams can continue to have all users/applications within the default team. This is the most liberal structure where all users have access to all applications as per their role.
- The different type of roles and their privileges are described in detail in the following article
Role based access control - Organization admins have team admin level privileges for all teams.
- Team memberships of SCIM provisioned users cannot be changed from the Deepfactor portal UI. Users should be added to /removed from required groups in the SSO provider and Deepfactor will sync those changes automatically.
Teams feature allows admins to achieve the following goals
- Principle of least privilege: Users of one team cannot view applications of other teams ensuring users have access only to the vulnerabilities associated with their applications.
- Reduce clutter: Ensure users view only the vulnerabilities that are relevant to them, reducing noise and clutter and helping them direct their focus on actionable insights.
- Different Integrations per team: Deepfactor allows teams to have integrations of their own. Example: Different teams can integrate with different jira accounts.
- Manage memberships from the Identity provider (idp): Deepfactor allows admins to manage team memberships from their idp, ensuring access to Deepfactor teams is managed centrally from the idp tool.
#
User & Team management #
Organization admins have the privileges to manage teams. They can create / delete teams, assign existing users / invite new users to teams and change org role and team role for users. Team admins cannot create / delete teams but can manage users within their team.
View teams #
In order to view all teams, org admins can navigate to ‘User Management’ (from left sidebar) -> ‘Teams’ (from left sidebar).
Create a team #
In order to create a team, org admins can navigate to ‘User Management’ (from left sidebar) -> ‘Teams’ (from left sidebar) and click on + Add Team button on the teams table. In the dialog, please enter the following details.
- Name
- Description
- Slug: A unique short name for the team. This can be used to pass team memberships from the idp as described in this section.
Delete a team #
Organization admins can delete a team by clicking on the delete (trash can icon) in the team row.
Please note:
- This action is irreversible and cannot be undone.
- All members of the team will be removed from the team.
- All the applications and artifacts associated with the deleted team will be marked for deletion and will not be accessible to any user in the organization. Existing instrumented applications will stop sending telemetry to the portal.
- If required, organization admins can create a new team with the same team name in the future. However, this would be a new team and members will need to be re-added to the team.
Add members to a team #
Organization and team admins can add existing users or invite new users to the team by clicking on the desired team and then clicking on the ‘Add members’ button. Invited users will receive an email and once they accept the invite, they will automatically be added to the invited team. Please note, SCIM provisioned users cannot be added to teams from the Deepfactor portal UI. They should be added to the appropriate groups in the SSO provider and Deepfactor will automatically sync the changes.
#
Remove members from a team #
Organization and team admins can remove existing from the team by clicking on the desired team, selecting the users that need to be removed and then clicking on the ‘Remove members’ button. Please note:
- Once you remove these users from the team, they will not be able to view the artifacts and applications associated with the team.
- They will continue to see artifacts and applications from the other teams they are a member of.
- Their run tokens associated with this team will be invalidated. All applications instrumented using such tokens will stop sending telemetry to the portal and they will need to be re-instrumented with a valid run token.
- If required, organization or team admins can re-add these users to the team in the future.
- SCIM provisioned users cannot be removed from teams from the Deepfactor portal UI. They should be removed from the appropriate groups in the SSO provider and Deepfactor will automatically sync the changes.
#
Configure team memberships and roles from idp #
Deepfactor allows organizations to manage team memberships from either the Deepfactor portal or from the SSO tool for Just in time (JIT) provisioned users. For the latter, you will need to configure a custom claim in the SSO provider.
As mentioned before, a few points of relevance regarding Deepfactor teams are
- A user can belong to zero, one or more teams.
- A user can have different roles per team
- Organization admins have team admin level privileges for all teams.
There are a couple of different ways for admins to manage team and role configuration of users from the idp tool.
- Default team and default role: When you integrate the idp tool with Deepfactor, you can provide a default team and default role for users who login using the idp tool.
- df_access: You can configure the idp to send df_access claim in the token sent to Deepfactor to express the team and role configuration for every user who logs in using the idp.
The following are the properties of the df_access claim.
- The claim df_access is of type string array.
- For org admins, df_access should be set to [df-orgadmin].
- For non org admins, each element in the array should specify a single team-role combination in the format df-{teamslug}-{role} where teamslug is the slug provided while creating the team and role is one of the team level roles specified in this document.
- Since df_access is an array, you can specify multiple team role combinations.
Some examples are given below:
df_access | Team Role combinations | Notes |
---|---|---|
[df-orgadmin] | Org admin | |
[df-orgadmin, df-apisvc-developer] | Org admin | Since df-orgadmin is present in the df_access array, all other entries (df-apisvc-developer) will be ignored. |
[df-apisvc-developer, df-transactionsvc-viewer] | Developer in API Service Viewer in Transaction Service |
|
[df-apisvc-invalidrole, df-transactionsvc-viewer] | Viewer in Transaction Service | df-apisvc-invalidrole is ignored as invalidrole does not match with any of the allowed team roles. |
[df-apisvc-invalidrole, df-transactsvc-viewer] | None | df-apisvc-invalidrole is ignored as invalidrole does not match any of the allowed team roles. df-transactsvc-viewer is ignored as transactsvc does not match any of the team slugs. |
[df-apisvc-invalidrole] | None | df-apisvc-invalidrole is ignored as invalidrole does not match any of the allowed team roles and the user is not added to any team |
[] | None | Since no team-role combination is sent in the df_access attribute, the user will not be added to any team. |
Default role in default team | If df_access claim is not sent in the token received from the idp, Deepfactor will automatically add the user to the default team with the default role selected during the setup of the idp integration. |