Team Support Considerations
This section lists the impact of the Team support feature on other API Gateway features.
As stated in previous sections, users can view only the assets that are assigned to their teams. Also, their accessibility depends on the functional privileges assigned to their team. Though this appears to be a simple behavior, there are some scenarios where it gets a little exceptional. Hence, as an administrator, read through the following scenarios carefully before you create team and assign functional privileges:
Visibility and Accessibility of Assets
You can use the Teams support feature to restrict the visibility and access of APIs, applications, packages, and plans. However, there are some scenarios where users from unassigned teams can view or access these assets. Also, note that the Teams support feature does not restrict the visibility and access of aliases, global policies, scopes, users, groups, and teams.
Scenarios that you must consider when using Team support
1. When an API assigned to a team is associated with applications that are assigned to some other teams, then the team members, to whom the API is assigned can view the applications and remove them if required.
For example, consider two teams Team_A and Team_B. The API API_1 and Application_1 are assigned to Team_A and the API API_2 and Application_2 are assigned to Team_B. If you associate Application_1 and Application_2 with API_1, then the Team_A members can view Application_2 and remove the application from API_1, if required.
2. Users can view assets other than APIs, applications, packages, and plans based on their functional privileges. So, the Team support feature does not have an impact on assets like aliases, global policies, scopes, users, groups, and teams.
For example, consider two APIs, API_1 and API_2 assigned to two different teams; API_1 assigned to Team_A and API_2 assigned to Team_B. Consider a global policy applied to both APIs and an endpoint alias used in both APIs. In this case, users from both teams can view the global policy and the endpoint alias used by these APIs and there is no way to restrict this behavior.
The following table helps you to quickly recall the points discussed earlier in this topic:
Asset type | Visibility | Accessibility |
APIs | Users can view the names, details, and versions of the APIs associated with their teams. | Users can access APIs based on functional privileges assigned to their teams. |
Users can view the names of applications that are associated with the APIs assigned to their teams. | Users can remove the applications that are visible (from the API). |
Applications | Users can view the names, descriptions, versions of the applications associated with their teams. | Users can access applications based on functional privileges assigned to their teams. |
| Users can view the names of APIs that are associated with the applications assigned to their teams. | Users can remove the APIs that are visible (from the application). |
Packages and plans. | Users can view the names and details of the packages and plans assigned to their teams. | Users can access packages and plans based on functional privileges assigned to their teams. |
Global search field | When users search for an asset using a keyword, the search returns only the assets that are assigned to your teams. | Users can access assets based on functional privileges assigned to their teams. |
Aliases, Global Policies, Users, Groups, Teams, and Scopes | All users can view these assets, even if they have read-only access to API Gateway. | User can access the assets based on the privilege assigned to the individual users, irrespective of their teams. |
Importing and Exporting Teams and Assets
Team members can import or export assets if they are assigned with the required functional privileges.
When assets are exported, the respective team details are exported along with the assets; members of the teams are not exported.
When assets are imported, the respective team is created if it is not present already; members of the teams cannot be imported.
When team is exported, the users and groups that are part of team can be selected for export if required.
When team is imported, the users and groups are imported along with the team.
An export archive of an API will include the details of all associated applications (if this option was selected when exporting) - "visible" and "invisible"
An export archive of an Application will always include the details of all associated APIs - "visible" and "invisible"
Promotion management
Users with Manage promotions privilege can see all associated APIs/Applications (visible and invisible) on the Assets and dependencies page for the Applications/APIs selected on the Search page of the Promotion Management wizard
By switching between the Search page and the Assets and dependencies page using the Back and Next buttons, they can even drill down and recursively see all dependent assets (visible and invisible)
Members of a team can promote assets from one source stage to one or more target stages if they have the required functional privileges.
When assets (all except teams) are promoted, they are promoted along with their team details; users are not promoted.
When teams are promoted, the users and groups of teams can be promoted if required.
Scope mapping
Users with Manage scope mapping privilege can see all APIs (including APIs otherwise invisible to them) on the scope mapping configuration page. They can even add them to a scope mapping, but they cannot remove them again
Scope mappings are visible to all users
API Gateway displays the names, descriptions, and versions for all associated APIs.
The API entries are not linked with the respective API details pages
Note that there will be a scope mapping for every API if pg_oauth2_createDefaultScopes is set to true, so every API is listed in the list of scope mappings - visible to all users
Global policies for APIs
Global policies are visible to all users
API Gateway displays names, descriptions, and versions for all associated APIs (by the policy's filter conditions)
Only the entries for the visible APIs are linked with their API details pages
API mashup
Users can add APIs owned by you or assigned to your Team, but in an existing API Mashup, you can see the names, versions, selected resources and methods of all configured APIs - even those invisible to you.
API versioning
On the API details page (for a visible API version), the API Gateway displays all version numbers in the version drop-down list - for versions visible and invisible to the current user
When the user selects an invisible version, API Gateway displays an error message.