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.