Feature ideas

The SSO flows are a bit awkward since they have to be initiated by the IdP at the moment. Adding SCIM support would allow us to configure third-party Identity Providers such as Okta, Auth0, or Azure AD to provision users and groups in our Port accounts, allowing users to authenticate through Port rather than initiating login through the Identity Provider.

As admin users, we have full visibility on everything that's available in Port. We can already control what users see and interact with, but we cannot easily confirm if the changes we have made are correctly tailored to them. It would be very helpful to be able to preview the changes.

At the moment you can only rotate the organization secret (from UI and API). Port should also have this ability for the personal secret

When a self service action is unable to be executed due to the dynamic permissions not allowing the execution, the error message logged provides no context about what specific part of the dynamic permission caused the action to be denied. This makes troubleshooting and building permissions incredibly difficult as you have no idea what part of the permissions policy/condition caused the error. The error message should explain what aspect of the policy's query/condition caused the rejection of the execution.

Managing dynamic permissions requires specific skills and is more challenging to debug and verify. To assist, we want to provide an improved UI that will allow us to test the result and verify users defined the permissions as expected.

It would be helpful to associate GitHub Team Members to the GitHub Teams themselves in Port, pulling in GitHub Users/Members as part of the Port Users. This mechanism could help drive the creation of GitHub Teams as Port Teams that indicate entity ownership and inheritance from the repo as well.

Sync groups and roles using the SCIM integration to ease groups management and overall portal permissions.

Implement a token rotation feature within Port to enhance security and compliance by automatically updating access tokens at predefined intervals. This capability will ensure that tokens used for authentication and API access are regularly refreshed, reducing the risk of token compromise.

At present it supports inheritance from a single blueprint. Where you have multiple blueprints which a PR entity can be associated with e.g. Microservice Tooling Library Would be nice to add OR tooling OR library where a relation doesn't exist on the initial check to complete the coverage of options for inheritance

Now, the only way to assign permissions over an entity is by using owning_teams property and configuring the ownedByTeam: true/false on the blueprint permissions. We would like to define custom teams arrays as properties that can be inherited from relations and assigned granular permissions over entities (just like owning_teams, but being custom properties).