diff --git a/modules/ROOT/pages/business-groups.adoc b/modules/ROOT/pages/business-groups.adoc index e86ab3e3..8752d518 100644 --- a/modules/ROOT/pages/business-groups.adoc +++ b/modules/ROOT/pages/business-groups.adoc @@ -5,7 +5,7 @@ Business groups are self-contained resource groups that contain Anypoint Platfor Business groups reside within the root organization and are organized in a hierarchical tree where the top-level business group is the root. Each business group you create has one direct parent and can have multiple children. [NOTE] -Business groups are not enabled by default in a new Anypoint Platform account. To activate business groups in your organization, contact your MuleSoft representative. There is a limit of 100 business groups per organization. +Business groups aren't enabled by default in a new Anypoint Platform account. To activate business groups in your organization, contact your MuleSoft representative. There is a limit of 100 business groups per organization. If you have the Organization Administrator permission and your organization is enabled for business group support, you can create and manage business groups within your organization. diff --git a/modules/ROOT/pages/connected-app-bearer-token-example.adoc b/modules/ROOT/pages/connected-app-bearer-token-example.adoc index 373c07e0..c4650466 100644 --- a/modules/ROOT/pages/connected-app-bearer-token-example.adoc +++ b/modules/ROOT/pages/connected-app-bearer-token-example.adoc @@ -1,6 +1,6 @@ = Getting the Bearer Token for a Connected App Example -This example demonstrates how to create a connected app that acts on its own behalf using client credentials to get the bearer token so you can invoke Anypoint Platform APIs. +Follow a step-by-step example to create a connected app that uses the client credentials grant type. Learn how to configure the necessary scopes and then retrieve an OAuth 2.0 bearer token for the app. Use this bearer token to securely invoke Anypoint Platform APIs for machine-to-machine interactions or automation tasks. [[create-connected-app]] == Create a Connected App diff --git a/modules/ROOT/pages/connected-apps-developers.adoc b/modules/ROOT/pages/connected-apps-developers.adoc index ec73ffee..1195a8e5 100644 --- a/modules/ROOT/pages/connected-apps-developers.adoc +++ b/modules/ROOT/pages/connected-apps-developers.adoc @@ -1,6 +1,6 @@ = Connected Apps for Developers -Anypoint Platform provides a https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/[comprehensive set of APIs] to extend functionality. +Leverage Anypoint Platform APIs securely by developing or using connected apps. Understand how connected apps use OAuth 2.0 and OpenID Connect to delegate access, enabling interactions like building CI/CD pipelines or integrating third-party services without exposing user credentials. Learn about authentication flows, token usage, and considerations like application allowlisting from a developer's perspective. The Connected Apps feature enables you to: @@ -22,7 +22,7 @@ To make the authentication experience consistent for end users, third-party deve Organization administrators can enable an allowlist to control which apps can access the organization's user data. -When your app is added to an allowlist, only the set of scopes associated with the app are reviewed and approved by the administrator. If you add new scopes to your app later, you’re unable to request those scopes from users until the admin reapproves your app. +When your app is added to an allowlist, only the set of scopes associated with the app are reviewed and approved by the administrator. If you add new scopes to your app later, you're unable to request those scopes from users until the admin reapproves your app. Existing authorizations and new authorizations using the previously allowlisted set of scopes continue to work. For more information, see xref:connected-apps-org-admin.adoc#application-allowlist-admin[connected apps for administrators]. diff --git a/modules/ROOT/pages/connecting-salesforce-orgs.adoc b/modules/ROOT/pages/connecting-salesforce-orgs.adoc index cbbec31e..a3beef10 100644 --- a/modules/ROOT/pages/connecting-salesforce-orgs.adoc +++ b/modules/ROOT/pages/connecting-salesforce-orgs.adoc @@ -1,9 +1,6 @@ = Establish a Tenant Relationship With a Trusted Salesforce Organization -Ways to establish a tenant relationship include: - -* A Salesforce organization is provisioned with the tenant relationship with an Anypoint Platform organization already established. In this case, the Anypoint Platform organization administrator just needs to xref:managing-connected-salesforce-orgs.adoc#enable-disable-connection[enable the connection] in Anypoint Platform. -* The Anypoint Platform organization administrator initiates the tenant relationship in Anypoint Platform and the Salesforce organization administrator completes the setup in the Salesforce organization. +Establish a trusted tenant relationship between your Anypoint Platform organization and a Salesforce organization to enable cross-platform features. Learn the steps required by both Anypoint Platform administrators and Salesforce administrators to connect the two platforms. This process typically involves initiating the connection in Anypoint Platform using the Salesforce tenant key and completing it in Salesforce using the Anypoint Platform organization key. In some cases, the Anypoint Platform organization administrator and Salesforce organization administrator are different people, and in some cases, they are the same person. diff --git a/modules/ROOT/pages/creating-connected-apps-dev.adoc b/modules/ROOT/pages/creating-connected-apps-dev.adoc index 2bd171a7..4ac2d82f 100644 --- a/modules/ROOT/pages/creating-connected-apps-dev.adoc +++ b/modules/ROOT/pages/creating-connected-apps-dev.adoc @@ -1,12 +1,14 @@ = Creating Connected Apps +Create connected apps within Anypoint Platform to enable external applications or services to interact securely with platform APIs. Learn how to configure apps that act on behalf of a user (using grant types like Authorization Code or JWT Bearer) or apps that act on their own behalf (using Client Credentials). Understand the process of assigning appropriate scopes, which map to platform permissions, to control the level of access granted to the connected app. + When you create connected apps, keep in mind: * Your organization can own up to 2000 connected apps at the root organization or business group level. * Each connected app can have up to 1000 scopes. * All scopes in the endpoint correspond directly to permissions available in Anypoint Platform, except for exceptions noted in <>. Scopes determine the level of permissions to provide to the app. * Your Anypoint Platform organization owns your app. Any organization administrator of the root organization or business group in which the app resides can control it. -* A unique `clientID` is automatically assigned and can’t be changed. +* A unique `clientID` is automatically assigned and can't be changed. * The `clientSecret` has no expiration date by default but you can change the expiration date. == Before You Begin @@ -70,12 +72,12 @@ This is an example of the development flow: . The authorization server sends a temporary authorization code back to the specified redirect URI. . The app calls the authorization server with the temporary code to receive the access token. + -The access token can now be used to call Anypoint Platform APIs on the user’s behalf. +The access token can now be used to call Anypoint Platform APIs on the user's behalf. [[refresh-token]] === Refresh Token -Use the `refresh_token` grant type to grant access to user data when the user isn’t signed in. Refresh tokens expire after 90 days. Access tokens expire after the user’s session expires. +Use the `refresh_token` grant type to grant access to user data when the user isn't signed in. Refresh tokens expire after 90 days. Access tokens expire after the user's session expires. To work with OpenID Connect, apps exchange refresh tokens for new access tokens after the initial authorization to continue accessing user data. @@ -86,10 +88,10 @@ To request a new access token, send a request to the token endpoint using the `r [[password]] === Password -Use the `password` grant type when the application exchanges the user’s username and password for an access token. +Use the `password` grant type when the application exchanges the user's username and password for an access token. [NOTE] -This grant type isn’t recommended, as it reveals user credentials directly to the connected app. This type also precludes the use of additional security measures, such as multi-factor authentication. +This grant type isn't recommended, as it reveals user credentials directly to the connected app. This type also precludes the use of additional security measures, such as multi-factor authentication. [[jwt-bearer]] === JWT Bearer Token @@ -105,7 +107,7 @@ The `jwt_bearer` grant type is suitable for use with trusted clients to gain acc | Attribute | Description | `iss` -| The issuer of the claim. This value must be same as the connected app’s `clientId`. +| The issuer of the claim. This value must be same as the connected app's `clientId`. | `sub` a| The subject of the token, such as: @@ -124,7 +126,7 @@ NOTE: At minimum, `identityProvider_id` and `username` are required for `sub`, a [[client-credentials]] === Client Credentials -Use the `client_credentials` grant type for machine-to-machine authentication when a specific user’s permission to access data isn't required. +Use the `client_credentials` grant type for machine-to-machine authentication when a specific user's permission to access data isn't required. The `client_credentials` grant type uses the `clientId` and `clientSecret` of the client to authorize and access protected data. diff --git a/modules/ROOT/pages/enabling-invocable-actions.adoc b/modules/ROOT/pages/enabling-invocable-actions.adoc index 1599652a..4d614cf6 100644 --- a/modules/ROOT/pages/enabling-invocable-actions.adoc +++ b/modules/ROOT/pages/enabling-invocable-actions.adoc @@ -1,6 +1,6 @@ = Enabling or Disabling Invocable Actions in the Salesforce Org -When the invocable actions capability is enabled by the Salesforce admin in Salesforce, MuleSoft automation developers can publish invocable actions directly from their Robotic Process Automations (RPA) and Composer flows to the connected Salesforce org. +MuleSoft automation developers can directly publish invocable actions from MuleSoft Robotic Process Automation (RPA) processes and Composer flows into a connected Salesforce org. This capability is controlled by the Salesforce administrator within the Salesforce setup interface. Enabling this feature streamlines the process of making MuleSoft automations available for use within Salesforce workflows. . In Salesforce Setup, enter `MuleSoft` in the *Quick Find* box, then select *MuleSoft > MuleSoft Anypoint Platform*. . In *Your connected Anypoint Platform Organization*, click *View Connection Info*. diff --git a/modules/ROOT/pages/external-identity.adoc b/modules/ROOT/pages/external-identity.adoc index 317aeb19..3bb8c024 100644 --- a/modules/ROOT/pages/external-identity.adoc +++ b/modules/ROOT/pages/external-identity.adoc @@ -2,11 +2,7 @@ :page-aliases: change-id-mgmt-conf-about.adoc, setting-up-external-identity.adoc -As the Anypoint Platform organization administrator, you can configure identity management in Anypoint Platform to set up users for single sign-on (SSO). An organization can have up to 25 external identity providers, or _IdPs_, configured for SSO. Configure identity management using one of the following single sign-on standards: - -* OpenID Connect: End user identity verification by an authorization server including SSO -+ -* SAML 2.0: Web-based authorization including cross-domain SSO +Configure external identity providers (IdPs) within Anypoint Platform to enable single sign-on (SSO) for your organization users. As an administrator, you can set up identity management using supported standards like OpenID Connect (OIDC) for verification or SAML 2.0 for web-based authorization. An organization can have up to 25 different IdPs configured simultaneously. This diagram shows the SAML identity management process: diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 92af6297..a99fcdd6 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -5,7 +5,7 @@ endif::[] :keywords: anypoint platform, permissions, configuring :page-aliases: anypoint-platform-for-apis-administration.adoc -Access Management enables you to xref:managing-your-account.adoc#how-to-create-your-account[create your Anypoint Platform account] and configure your user profile. +Control user access, manage organizational structures, and configure security settings within Anypoint Platform using Access Management. Define how users authenticate via internal credentials or external identity providers (IdPs) using SAML/OIDC for single sign-on (SSO), and enforce multi-factor authentication (MFA). Organize resources and permissions through business groups, environments, and the Teams feature to ensure users and client applications have appropriate access levels. For organization owners and administrators, Access Management enables you to: diff --git a/modules/ROOT/pages/manage-capabilities.adoc b/modules/ROOT/pages/manage-capabilities.adoc index 794c5574..66175d93 100644 --- a/modules/ROOT/pages/manage-capabilities.adoc +++ b/modules/ROOT/pages/manage-capabilities.adoc @@ -1,6 +1,6 @@ = Managing Capabilities for a Connected Salesforce Organization -When you establish a tenant relationship and enable the connection between your Anypoint Platform organization and a trusted Salesforce organization, you can enable and disable capabilities associated with the Salesforce organization. +Control the integration between your Anypoint Platform and Salesforce organizations by managing specific capabilities. After establishing a trusted connection, selectively enable or disable features like Einstein Activity Capture or Invocable Actions based on your business needs. This ensures you only expose the necessary functionality for the integration. * xref:enabling-einstein.adoc[] * xref:enabling-invocable-actions.adoc[] diff --git a/modules/ROOT/pages/managing-connected-salesforce-orgs.adoc b/modules/ROOT/pages/managing-connected-salesforce-orgs.adoc index f3ec4b44..05e53bc8 100644 --- a/modules/ROOT/pages/managing-connected-salesforce-orgs.adoc +++ b/modules/ROOT/pages/managing-connected-salesforce-orgs.adoc @@ -1,6 +1,6 @@ = Managing Connected Salesforce Orgs -As an Anypoint Platform organization administrator, you can enable, remove, and repair connections, and edit the name of Salesforce organizations. +Maintain the connections between your Anypoint Platform organization and trusted Salesforce organizations. As an administrator, learn how to enable newly established tenant relationships to activate cross-platform features. You can also repair connections if Salesforce domain details change, edit the displayed Salesforce organization name for clarity, or permanently remove connections when they are no longer needed. [enable-disable-connection] == Enable the Connection in Anypoint Platform diff --git a/modules/ROOT/pages/managing-permissions.adoc b/modules/ROOT/pages/managing-permissions.adoc index 1dcdcb40..bf85c849 100644 --- a/modules/ROOT/pages/managing-permissions.adoc +++ b/modules/ROOT/pages/managing-permissions.adoc @@ -5,7 +5,7 @@ endif::[] :keywords: anypoint platform, permissions, configuring, accounts, roles :page-aliases: managing-accounts-roles-and-permissions.adoc -This section explains how permissions work across different products and APIs managed from the Anypoint Platform. +Control user access across Anypoint Platform by understanding and managing permissions effectively. Assign appropriate capabilities through roles (deprecated) or the recommended Teams feature to regulate access to specific products, APIs, environments, and business groups. Properly configured permissions ensure users have the necessary access while maintaining security and compliance. To manage permissions, you must have the Organization Administrator permission in your organization, have the Organization Administrator permission over one of the business groups of your organization, or have API Version Owner permissions and want to manage user permissions for an API version, a business group or the entire organization. diff --git a/modules/ROOT/pages/managing-your-account.adoc b/modules/ROOT/pages/managing-your-account.adoc index 3aee111d..4711c15d 100644 --- a/modules/ROOT/pages/managing-your-account.adoc +++ b/modules/ROOT/pages/managing-your-account.adoc @@ -4,6 +4,8 @@ include::_attributes.adoc[] endif::[] :keywords: anypoint platform, permissions, configuring, accounts +Manage your Anypoint Platform user account settings and access. Learn how to create a new account, join an existing organization via invitation, or sign in using various methods including single sign-on (SSO). Keep your user profile information up-to-date and understand how account association impacts organization ownership. + == Create an Anypoint Platform Account [NOTE] diff --git a/modules/ROOT/pages/private-cloud-edition-features.adoc b/modules/ROOT/pages/private-cloud-edition-features.adoc index 9a12085c..fd13f1d8 100644 --- a/modules/ROOT/pages/private-cloud-edition-features.adoc +++ b/modules/ROOT/pages/private-cloud-edition-features.adoc @@ -1,6 +1,6 @@ = Private Cloud Edition Features -Anypoint Platform Private Cloud Edition enables you to: +Manage specific Access Management features unique to Anypoint Platform Private Cloud Edition (PCE). Configure essential components like LDAP for user management and an SMTP server for sending alerts directly from your private installation. You can also customize security settings with your own SSL certificates and add a disclaimer to the login page. . Configure xref:external-identity.adoc#user-management[User Management] using xref:external-identity.adoc#configure-ldap[LDAP]. . Configure an <> to send API Manager alerts from your Anypoint Platform Private Cloud Edition installation. diff --git a/modules/ROOT/pages/saml-bearer-token.adoc b/modules/ROOT/pages/saml-bearer-token.adoc index 06ad42ef..ccdd5cfd 100644 --- a/modules/ROOT/pages/saml-bearer-token.adoc +++ b/modules/ROOT/pages/saml-bearer-token.adoc @@ -1,7 +1,7 @@ = Obtaining an API Bearer Token Using a SAML Assertion -If you are using an identity provider configured to use SAML 2.0, federated users within your organization can access Anypoint Platform APIs using the bearer token . +Exchange a SAML 2.0 assertion obtained from your identity provider (IdP) for an Anypoint Platform API bearer token. This process allows federated users or applications acting on their behalf to authenticate programmatically for API access, specifically using an IdP-initiated flow. Learn how to capture the SAML response and use it in a request to the Anypoint Platform token endpoint to receive the bearer token. [NOTE] Obtaining an API bearer token using a SAML assertion works only for IdP-initiated single signon. Service provider-initiated SSO does not support unsolicited assertions. diff --git a/modules/ROOT/pages/single-log-out-task.adoc b/modules/ROOT/pages/single-log-out-task.adoc index baaafc02..12cbfa6c 100644 --- a/modules/ROOT/pages/single-log-out-task.adoc +++ b/modules/ROOT/pages/single-log-out-task.adoc @@ -1,34 +1,34 @@ -= Configuring Single Signout += Configuring Single Sign out ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -As Administrator, you can configure single signout if you use SAML. OpenID Connect doesn't support single signout. Using single signout, a user or user agent can sign out of an authenticated environment and ensure that both service providers and identity servers process the signout correctly. +As Administrator, you can configure single sign-out if you use SAML. OpenID Connect doesn't support single sign-out. Using single sign-out, a user or user agent can sign out of an authenticated environment and verify that both service providers and identity servers process the sign-out correctly. -The following procedure shows how to perform single signout and control where the user is redirected after signing out. +This procedure shows how to perform single sign-out and control where the user is redirected after signing out. To redirect the user to a different page, set up the redirect in your PingFederate configuration by adding a `redirect_uri` query parameter to the SLO Service URL. Anypoint Platform routes the user to that page rather than to the Anypoint Platform sign-in page. . In PingFederate, for example, click the SP Configuration for the Anypoint Platform. -. In *Browser SSO > Configure Browser SSO > SAML Profiles*, ensure that these fields are set: +. In *Browser SSO > Configure Browser SSO > SAML Profiles*, verify that these fields are set: + * IdP-Initiated SSO * IdP-Initiated SLO * SP-Initiated SLO + -. In *Protocol Settings > Configure Protocol Settings*, configure a SLO Service URL with the following values: +. In *Protocol Settings > Configure Protocol Settings*, configure a SLO Service URL with these values: + * Binding: POST * Endpoint URL + Set `PARTNER_SP_ID` to the correct value: `+https://anypoint.mulesoft.com/accounts/logout/receive-id+` + -. Redirect users to your sign-in page using the following URL: +. Redirect users to your sign-in page using this URL: + ---- https://anypoint.mulesoft.com/accounts/logout/receive-id?redirect_uri=https%3A%2F%2Fanypoint.mulesoft.com%2Faccounts%2Flogin%2Fyour-domain ---- + -Alternatively, redirect users to your portal page using the following URL: +Alternatively, redirect users to your portal page using this URL: + ---- https://anypoint.mulesoft.com/accounts/logout/receive-id?redirect_uri=https%3A%2F%2Fanypoint.mulesoft.com%2Fapiplatform%2Fyour-domain%2F%23%2Fportals @@ -37,7 +37,7 @@ https://anypoint.mulesoft.com/accounts/logout/receive-id?redirect_uri=https%3A%2 . In *Allowable SAML Bindings*, click *Redirect*. . In *Encryption Policy*, choose either *none* or *the entire assertions*, then save and exit Protocol Settings and Browser SSO. . When viewing the SP Configuration for Anypoint Platform, go to *Credentials > Configure Credentials*. -. Set *Signature Verification Settings > Manage Signature Verification Settings > Trust Model to Unanchored*, and import the certificate from the following location: +. Set *Signature Verification Settings > Manage Signature Verification Settings > Trust Model to Unanchored*, and import the certificate from this location: + `+http://docs.mulesoft.com/downloads/access-management/anypoint-platform-slo.pem+` + diff --git a/modules/ROOT/pages/sso-prerequisites-about.adoc b/modules/ROOT/pages/sso-prerequisites-about.adoc index 118b49b0..4d2c8fa4 100644 --- a/modules/ROOT/pages/sso-prerequisites-about.adoc +++ b/modules/ROOT/pages/sso-prerequisites-about.adoc @@ -1,6 +1,6 @@ = SSO Prerequisites and Limitations -When using SSO within Anypoint Platform, there are some prerequisites and limitations to be aware of. +Prepare for a successful single sign-on (SSO) implementation by understanding the necessary prerequisites and potential limitations within Anypoint Platform. Ensure your identity provider (IdP) is correctly configured to send required user attributes and handle signed/encrypted SAML assertions. Be aware of specific client behaviors and limitations related to session timeouts, external identity scope, and user management when using SSO. == Before You Begin diff --git a/modules/ROOT/pages/teams-example.adoc b/modules/ROOT/pages/teams-example.adoc index 99a25d78..6de67e09 100644 --- a/modules/ROOT/pages/teams-example.adoc +++ b/modules/ROOT/pages/teams-example.adoc @@ -1,6 +1,6 @@ = Example Teams Structure -Imagine that your organization, Acme, includes a team called Engineering that contains smaller teams that focus on building specific components. The Identity and DevOps teams are specialized teams within the larger Engineering team. +Understand how to structure teams effectively using a practical example. See how a hypothetical organization, Acme, uses a main Engineering team with specialized Identity and DevOps sub-teams to manage permissions efficiently. This hierarchical approach helps delegate access based on specific roles and responsibilities. Using the Teams feature, you can structure your users and permissions in the following way: diff --git a/modules/ROOT/pages/test-external-identity-task.adoc b/modules/ROOT/pages/test-external-identity-task.adoc index 95f39909..2d906597 100644 --- a/modules/ROOT/pages/test-external-identity-task.adoc +++ b/modules/ROOT/pages/test-external-identity-task.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -After configuring your organization's external identity provider, test the integration. Obtain your organization's signin URL, for example: `+https:/anypoint.mulesoft.com/accounts/login/{organization-domain-name}+` by following these steps: +Verify that your external identity provider (IdP) integration for single sign-on (SSO) is functioning correctly. Learn how to obtain your organization's specific sign-in URL from the Access Management settings. Test the complete login flow by navigating to this URL, authenticating with a test user via your IdP, and confirming successful redirection back to Anypoint Platform. include::partial$include-nav-steps-org-admin.adoc[] diff --git a/modules/ROOT/pages/troubleshoot-access-management.adoc b/modules/ROOT/pages/troubleshoot-access-management.adoc index 3a5e660e..ee850fd5 100644 --- a/modules/ROOT/pages/troubleshoot-access-management.adoc +++ b/modules/ROOT/pages/troubleshoot-access-management.adoc @@ -1,6 +1,6 @@ = Troubleshoot Access Management -These tips provide information on what to do if you encounter issues. +Resolve common problems encountered within Anypoint Platform Access Management. Find potential solutions for issues related to signing in, such as unrecognized credentials or problems with external identity provider URLs. Address errors encountered during OpenID Connect client management or invitation link failures. == Problems with Accessing Anypoint Platform diff --git a/modules/ROOT/pages/troubleshoot-saml-assertions-task.adoc b/modules/ROOT/pages/troubleshoot-saml-assertions-task.adoc index ee6c47b2..f3008026 100644 --- a/modules/ROOT/pages/troubleshoot-saml-assertions-task.adoc +++ b/modules/ROOT/pages/troubleshoot-saml-assertions-task.adoc @@ -1,6 +1,6 @@ = View a SAML Response in the Browser -To view your SAML response in a browser, perform a single sign-on (SSO) and use the developer tools in your browser to find the bearer token and SAML response. +Troubleshoot single sign-on (SSO) issues by capturing the SAML response directly within your web browser. Perform an SSO login attempt and then use your browser's developer tools to inspect the network traffic. This allows you to find and analyze the SAML assertion details, which is essential for diagnosing configuration problems or providing information to support. [NOTE] Complete this task before calling the MuleSoft Support team to assist you in troubleshooting your SAML 2.0 compliant SSO setup. diff --git a/modules/ROOT/pages/troubleshooting-anypoint-platform-access.adoc b/modules/ROOT/pages/troubleshooting-anypoint-platform-access.adoc index ed1c3012..abf116ae 100644 --- a/modules/ROOT/pages/troubleshooting-anypoint-platform-access.adoc +++ b/modules/ROOT/pages/troubleshooting-anypoint-platform-access.adoc @@ -4,6 +4,8 @@ include::_attributes.adoc[] endif::[] :keywords: anypoint platform, permissions, configuring, limits +Find answers to common questions regarding access and administration within Anypoint Platform. Understand who can access specific features like Access Management or audit logs, and learn about platform limits for various resources like users, environments, and permissions. This guide also covers frequently asked questions about account management, invitations, and API access. + [[access-IAM]] == Access and Administration diff --git a/modules/ROOT/pages/trusted-salesforce-org.adoc b/modules/ROOT/pages/trusted-salesforce-org.adoc index 1807593d..ca361e18 100644 --- a/modules/ROOT/pages/trusted-salesforce-org.adoc +++ b/modules/ROOT/pages/trusted-salesforce-org.adoc @@ -1,6 +1,6 @@ = Trusted Salesforce Organizations -Enable cross-platform features between your Anypoint Platform organization and a trusted Salesforce organization (tenant) by establishing a connection between them. +Connect your Anypoint Platform organization with one or more trusted Salesforce organizations (tenants) to enable powerful cross-platform features. Establishing this tenant relationship allows seamless integration, such as syncing APIs via API Catalog, publishing invocable actions from RPA or Composer, and enhancing developer tools with Einstein. Manage these connections to control which features are active between the platforms. Establishing a tenant relationship between an Anypoint Platform organization and a Salesforce organization enables users in your organization to: diff --git a/modules/ROOT/pages/update-user-profile-task.adoc b/modules/ROOT/pages/update-user-profile-task.adoc index 3a80b16e..83605204 100644 --- a/modules/ROOT/pages/update-user-profile-task.adoc +++ b/modules/ROOT/pages/update-user-profile-task.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -When you sign in to the configured IdP for the first time, an Anypoint user is created using your IdP information. +Update your Anypoint Platform user profile information automatically by signing in via your configured external identity provider (IdP). Understand how Anypoint Platform maps claims like `preferred_username`, `email`, and `sub` from the IdP to create or update your profile details. Subsequent logins through the IdP will refresh your profile with the latest information provided by the IdP. Your user profile includes a username, your name, and email address. Typically, the OpenID Connect `userinfo` endpoint provides a `preferred_username` claim that contains the authenticated user’s username. However, some IdPs such as OpenAM and PingFederate do not support the `preferred_username` claim. Therefore, when Anypoint Platform creates a user, the `email` and `sub` claim values comprise the username if the `preferred_username` claim isn't present. Claims are made in the following order: `preferred_username`, `email`, `sub`. If a username is created as a single string of random characters and does not have an email address defined, the string may be returning the `sub` claim that the `id` token and `userinfo` endpoint show for the user. diff --git a/modules/ROOT/pages/users.adoc b/modules/ROOT/pages/users.adoc index cfa817bc..665306e4 100644 --- a/modules/ROOT/pages/users.adoc +++ b/modules/ROOT/pages/users.adoc @@ -1,6 +1,6 @@ = Managing Users -As an administrator of your root organization, you can enable, disable, or delete users, assign permissions to users, and edit a user's settings. +Manage user accounts within your Anypoint Platform root organization as an administrator. Learn how to invite new users, enable or disable existing accounts, and assign or revoke permissions individually or through teams/roles. Understand the implications of deleting users and how to manage pending invitations or reset user passwords. On the access management *Users* page, you can: diff --git a/modules/ROOT/pages/verify-saml-info-task.adoc b/modules/ROOT/pages/verify-saml-info-task.adoc index 77ecc5ff..1962140e 100644 --- a/modules/ROOT/pages/verify-saml-info-task.adoc +++ b/modules/ROOT/pages/verify-saml-info-task.adoc @@ -3,7 +3,7 @@ ifndef::env-site,env-github[] include::_attributes.adoc[] endif::[] -During verification of SAML information, if you determine that information must be changed, sign in to the MuleSoft Support Portal and submit a request. +Confirm that your SAML 2.0 single sign-on (SSO) configuration within Anypoint Platform contains the correct information provided by your identity provider (IdP). Check key settings like the Group Attribute Name by navigating to the SAML 2.0 section in Access Management. If discrepancies are found that require modification by MuleSoft, contact support. . In Anypoint Platform, click Access Management > External Identity. . From Identity Management, select SAML 2.0.