Hila Kashai
updated the status to
in progress
Hila Kashai
Merged in a post:
Use current user's session to interact with internal systems
Alon Moscovitz
We'd like to enable identity or user session propagation capabilities, allowing Self-Service Actions (SSAs) triggered within Port to be executed using the context and permissions of the currently logged-in user. When an authenticated user initiates an SSA that interacts with external systems or resources, the action should be performed on behalf of that user, inheriting their identity, role-based access controls (RBAC), and authorized privileges from the same Identity and Access Management (IAM) provider used by Port, which is Okta.
For example, if an employee triggers an SSA to update a ticket in a service management system like Jira, the update should be carried out using that employee's credentials and permissions within Jira, which are derived from the same Okta IAM provider that Port uses for authentication and authorization. Similarly, if an SSA involves provisioning resources in a cloud platform, it should leverage the logged-in user's identity and access rights from Okta to ensure the provisioning adheres to their authorized roles and scopes defined within the shared IAM provider.
By propagating the user's identity and session context from the common Okta IAM provider, we can maintain a consistent access control model across Port and integrated systems, ensuring that actions are performed with the appropriate level of authorization and adhering to the organization's security policies and governance rules defined within the centralized Okta IAM solution.
Hila Kashai
updated the status to
planned
Hila Kashai
Merged in a post:
Per‑User Impersonation / Delegated Execution for Actions
A
Andrei Sergio Rodriguez Barriga
We need Port to support executing self‑service actions as the real user, not as a shared technical account. Today, actions that call tools like GitHub or Jira are executed with an app token, so in those tools every change appears as coming from a generic user. This breaks per‑user traceability required by an external zero‑trust banking audit, is considered a high security risk, and blocks us from safely scaling self‑service to 1,500+ engineers and multiple companies in our group.
Requested capability:
* OAuth2‑based delegated authorization so each Port user can link their own GitHub/Jira account and actions run with their token.
* A consistent “execute as user” model across integrations (GitHub first, then Jira, others later).
* Configurable backend for actions: keep current “machine token” mode, and add a new user‑session/OAuth mode that respects Port RBAC and IdP policies.
This is a blocker for audit compliance, enterprise‑wide adoption, and for comparing Port fairly with other IDPs that already support per‑user execution.
A
AnilKumarReddy Gajulapalli
In our environment, many users intentionally do not have direct permissions in the cloud. If Port executes actions using the user’s session in a way that allows them to perform operations they are not authorized to perform directly in the cloud, that effectively creates a privilege escalation path.
Users should not be able to perform actions through Port that they cannot perform in the underlying system. Any implementation must strictly enforce the target system’s native RBAC and permission model. Otherwise, this would pose a security risk.
E
Eric Storck
We have a similar need - we have actions that we would like users to trigger, but the permissions are nuanced (for example allowed for users on one repo in GitHub, but not on repos the user doesnt have GitHub permissions for). Being able to use authorization for external systems would really open the flexibility we can provide without dual managing permissions across systems.
S
Shilton JoJo
We are trying to use an LLM chat bot to connect with the Port MCP service and execute actions as the user who initiated it.
This is currently not possible since the bot cannot assume the user's identity using oauth.
T
Teddy Caddy
I'm facing a similar issue where we changed identity providers from Google to Entra AD, but the self service actions generate HTTP requests with a payload that doesn't provide Entra AD identity information. Instead it still sends the Google identity information.
T
Teddy Caddy
Now I'm seeing that new users who've never auth'd with Google don't have any metadata about their identity at Entra AD and I'm quite upset about it. We paid the SSO tax when we migrated from Google to Entra AD and I'm shocked to see that we don't get SSO identity in the payloads. I wish I had the foresight to ask about this assumption before we became paying customers. I am very disappointed and I hope this feature is added soon.