vania-janet/multiturn-rag-retrieval-data huggingface dataset:
name='Example Enterprise',
primary_contact_iam_id=contact_iam_id,
).get_result()

print(json.dumps(create_enterprise_response, indent=2))

createEnterpriseOptions := enterpriseManagementService.NewCreateEnterpriseOptions(
srcAccountID,
"Example Enterprise",
contactIamID,
)

createEnterpriseResponse, response, err := enterpriseManagementService.CreateEnterprise(createEnterpriseOptions)
if err != nil {
panic(err)
}
b, _ := json.MarshalIndent(createEnterpriseResponse, "", " ")
fmt.Println(string(b))

const params = {
sourceAccountId: srcAccountId,
name: 'Example Enterprise',
primaryContactIamId: contactIamId,
};

enterpriseManagementService.createEnterprise(params)
.then(res => {
console.log(JSON.stringify(res.result, null, 2));
})
.catch(err => {
console.warn(err)
});





 Creating an enterprise by using Terraform 

Use the following steps to create an enterprise:



1. Create an argument in your main.tf file. The following example creates an enterprise by using the ibm_enterprise resource, where name is a unique name to identify the enterprise. You must have an existing IAM ID of an enterprise primary contact in order to complete the task.

resource "ibm_enterprise" "enterprise" {
source_account_id = <source_account_id>
name = <name>
primary_contact_iam_id = <primary_contact_iam_id>
}

You can specify the ID of an account that is used to create the enterprise on the source_account_id option.
!!!!!! API key as follows.
<-- <ol> -->

1. From the menu bar, click Manage > Access (IAM).
2. Click the Users page and then select yourself.
3. In the API keys pane, click Create an IBM Cloud API key.
4. Enter a Name and Description for your API key and click Create.
5. Click Show to see the API key that was generated for you.
6. Copy the API key so that you can use it to retrieve your new IBM Cloud IAM access token.

<-- </ol> -->

<-- </ul> -->Use the following steps if you want to create an IBM Cloud IAM token or if you want to obtain a new refresh token.<-- <ol> -->1. Generate a new IBM Cloud IAM access token by using the refresh token or the IBM Cloud API key.
POST https://iam.cloud.ibm.com/identity/token

Header
: <-- <ul> -->

* Content-Type: application/x-www-form-urlencoded
* Authorization: Basic Yng6Yng=: Where Yng6Yng= equals the URL-encoded authorization for the username bx and the password bx.

<-- </ul> -->

Body when using the refresh token
: <-- <ul> -->

* grant_type: refresh_token
* response_type: cloud_iam uaa
* refresh_token: Your IBM Cloud IAM refresh token.
* uaa_client_ID: cf
* uaa_client_secret:
* bss_account: Your IBM Cloud account ID. Add the uaa_client_secret key with no value specified.

<-- </ul> -->

Body when using the IBM Cloud API key
: <-- <ul> -->

* grant_type: urn:ibm:params:oauth:grant-type:apikey
Service IDs are another type of identity that is used in an account. Service IDs are used to provide a separate identity for services and applications. Service IDs are best used when an application or service needs a digital identity and needs access to only IAM-enabled resources. You can create a service ID to be used by an application that needs access to your IBM Cloud services so that individual user credentials don't need to be used.



 Service ID API keys 

You can also create API keys that are associated with service IDs to authenticate applications as a particular service ID. This way, the applications can access resources that are assigned to that specific service ID. Service ID API key credentials can be used to make API and CLI calls. For more information about creating API keys associated with a service ID, see [Managing service ID API keys](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeysserviceidapikeys).







 Trusted profiles 

Similar to other identities within IAM, trusted profiles are treated as a subject that is granted access in IAM policies.

Usually, for a user to take an action on a resource within an account, that identity must explicitly be added to the account. With trusted profiles, it is possible for a user to complete the actions without being invited to an account. Instead, they are automatically granted access to resources when they apply the trusted profile identity during login. Only users federated by an external IdP can be mapped to trusted profiles during login by evaluating SAML-based attributes to determine which profiles their identity can apply.

Similarly, instead of creating a service ID, generating an API key, and getting the application to store and validate that key, you can create [trusted profiles for compute resources](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile) to define fine-grained authorization for all applications that are running in a compute resource. Compute resources become identities when used as part of a trusted profile. Trust with compute resources is established by conditions based on resource attributes, or creating a direct link to a specific resource.
Preregistering future users 

With IBM Cloud® App ID, you can start building a profile for users that you know are going to need access to your app before their initial sign-in.

To learn more about the security considerations that might apply when you work with custom attributes, see [Storing and accessing user profiles](https://cloud.ibm.com/docs/appid?topic=appid-profiles).



 Understanding preregistration 

There might be times when you are developing an application that you already know who your app users are going to be. These users are known as "future users". You might know ahead of time that certain users need specific permission levels or a specific food preference before they ever start interacting with your app. For example, you work for a development company and you hire a new person to function as a team lead. You might want to assign that user admin access to your app before they start so that when they sign in the first time, they can immediately start working without any further interaction on your part. Say that same person is a vegetarian. By noting it as a custom attribute in their profile, the preference can be pulled for all team lunches without them having to remind you.

By default, the ability for users to change their own custom attributes through the application is set to off. You can give your users that ability, but before you do be sure that you understand and have considered the [security issues](https://cloud.ibm.com/docs/appid?topic=appid-profilesprofile-set-custom) that can arise.

To assign custom attributes for future users, you can use either [the GUI](https://cloud.ibm.com/docs/appid?topic=appid-preregisterpreregister-gui) or the [preregistration endpoint](https://cloud.ibm.com/docs/appid?topic=appid-preregisterpreregister-api).



 How are users identified? 

You can identify your users by using one of the following:



* The email address with which the user signs in to your app.
Record the returned configuration_id of the newly created configuration.
3. Create a new collection using the [Collections API](https://cloud.ibm.com/apidocs/discoverycreate-a-collection). The object defining the collection must contain the configuration_id that you recorded earlier.



The source crawl begins as soon as you create the collection. After the initial crawl, all subsequent crawls run on the frequency that you specified. For information about managing a collection, see [Manage collections](https://cloud.ibm.com/docs/discovery?topic=discovery-sourcesmanage-collections).

If you modify anything in the source object of the configuration, a new crawl starts at that time or restarts if one is already running.



 Specifying a customer_id 

A customer_id field in an ingested Discovery document can be used to delete content based on the customer_id using the user-data method in the API. Incoming documents from a data source are not automatically assigned a customer_id when ingested. If your application requires a customer_id to be defined, you can specify one (or more) of the incoming fields from the source system to be copied and used as a customer_id. To do this you must modify the configuration that is being used to connect to the source.



1. Perform a sample query and identify which field you want to use as a customer_id.
2. Modify the configuration. Add a Normalization section to create the customer_id field.



* In the tooling, navigate to your collection and click the edit link in the configuration section. Next, click the Normalization tab and add in a copy normalization to create the customer_id field. Then click Apply & save. ![Copy normalization](https://cloud.ibm.com/docs-content/v1/content/ded4adc3ea0bd2a81b113c579f2b1183926da211/discovery/images/norm_copy.png)
* When you use the API, add the following object to the normalizations array:

{
"operation" : "copy",
Because App ID is the identity provider, users can take advantage of advanced functionality, such as resetting their password, directly in your app.

Working with application identity? Check out [Application identity](https://cloud.ibm.com/docs/appid?topic=appid-app).

Several identity providers can be configured to be used by App ID. Check out the following table to learn about your options.



Table 1. Identity provider options

 Identity provider Type Description 

 [Cloud Directory](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directory) Managed registry You can maintain your own user registry in the cloud. When a user signs up for your app, they are added to your directory of users. This option gives your users more freedom to manage their own account within your app. 
 [SAML](https://cloud.ibm.com/docs/appid?topic=appid-enterpriseenterprise) Enterprise You can create a single sign-on experience for your users. 
 [Facebook](https://cloud.ibm.com/docs/appid?topic=appid-socialfacebook) Social Users can sign in to your app by using their Facebook credentials. 
 [Google+](https://cloud.ibm.com/docs/appid?topic=appid-socialgoogle) Social Users can sign in to your app by using their Google credentials. 
 [Custom](https://cloud.ibm.com/docs/appid?topic=appid-custom-identitycustom-identity) Custom If none of the provided options fit your specific need, you can configure your own identity flow to work with App ID. 





 Managing providers 

An identity provider creates and manages information about an entity such as a user, a functional ID, or an application. The provider verifies the identity of the entity by using credentials, such as a password. Then, the IdP sends the identity information back to App ID, which authorizes the user and then grants access to your app.



1. Navigate to your service dashboard.
2. In the Identity Providers section of the navigation, select the Manage page.
Because the API key that is associated with your user identity has all of the access you're entitled to across any account that you are a member of, you must be cautious with how you use your API key. For example, an IBM Cloud service might need to act on behalf of a user or access services that are not IAM-enabled, so the service might request a user API key. In these cases, it is recommended that you create an API key that is associated with a functional ID that is assigned the minimum level of access that is required to work with the service.

A functional ID is a user ID created to represent a program, application, or service. The functional ID can be invited to an account and assigned only the access for a particular purpose, such as interacting with a specific resource or application. The functional ID should be granted only the minimum level access in a single account that is needed for the specific function, which it was created.

If you are applying a trusted profile, you can't create a user API key. You can still create and manage all other API keys. For example, service ID API keys. For more information, see [FAQs about IAM](https://cloud.ibm.com/docs/account?topic=account-iamfaqtp-apikey).



 Managing user API keys 

To manage the IBM Cloud API keys that are associated with your user identity or the ones that you have access to manage for other users in the account, go to Manage > Access (IAM) > API keys in the IBM Cloud console. On the API keys page, you can create, edit, or delete IBM Cloud API keys for yourself, and you can manage all [classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys) for users that you are an ancestor of in the user hierarchy. In addition, if you are the account owner or a user assigned the required access to manage other user's API keys in the account, you can use the View filter to list and manage those API keys too.



Table 1. Required access for API key management on the API keys page

 Filter Options Displayed API Keys Required Access Allowed Actions
Create a Wave and define Wave name.
3. If there are multiple hosts, download the template, complete the appropriate fields, and then upload the template.
4. Select the Wave name to enter source and target information.
5. Select the "+" sign.
6. Add source IP address or FQDN and add source username.
7. Target Type = Existing system
8. Sync Type = Direct sync
9. Add target IP address or FQDN.
10. Add a target-friendly name, and add a target username.
11. Start the migration.



The username field for Linux environments is root. The username field for Windows environments is SYSTEM.





 Step 7: Validate your migration 

After your server migration, validate your compute resources, such as applications and data, and update or validate the following:



1. Access the target server.
2. Check partitions and volumes.
3. Check the applications.
4. Install any test application in target server.
5. Check networking routes.
6. Check or update your yum repos, application settings, and configuration file.
7. Check or update application or operating system licenses.
8. Remove the RMM SSH key.
Select an MSP ID for your organization. The MSP ID is the formal name of your organization within the consortium. The MSP ID used to create the organization MSP needs to be the same that you use to deploy your peers.2. Select a display name for your MSP.3. You need to provide the signCert, in base64 format, of your organization administrator that you registered and enrolled by using the Fabric CA client.
Navigate to the MSP directory that was created when you generated certificates by using your organization administrator]generate certificates for the admin].

cd $HOME/fabric-ca-client/peer-admin/msp

In this MSP directory, open the signCert file of the new user and convert it to base64 format by using the following commands:

export FLAG=$(if "$(uname -s)" == "Linux" ]; then echo "-w 0"; else echo "-b 0"; fi)
cat $HOME/<path-to-peer-admin>/msp/signcerts/cert.pem | base64 $FLAG

Note: It is important that the string generated by using the command above is formatted as a single line. It should look similar to:

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlFbERDQ0EzeWdBd0lCQWdJUUFmMmo2MjdLZGNpSVE0dHlTOCs4a1RBTkJna3Foa2lHOXcwQkFRc0ZBREJoDQpNUXN3Q1FZRFZRUUdFd0pWVXpFVk1CTUdBMVVFQ2hNTVJHbG5hVU5sY25RZ1NXNWpNUmt3RndZRFZRUUxFeEIzDQpkM2N1WkdsbmFXTmxjblF1WTI5dE1TQXdIZ1lEVlFRREV4ZEVhV2RwUTJWeWRDQkhiRzlpWVd3Z1VtOXZkQ0JEDQpRVEFlRncweE16QXpNRGd4TWpBd01EQmFGdzB5TXpBek1EZ3hNakF3TURCYU1FMHhDekFKQmdOVkJBWVRBbFZUDQpNUlV3RXdZRFZRUUtFd3hFYVdkcFEyVnlkQ0JKYm1NeEp6QWxCZ05WQkFNVEhrUnBaMmxEWlhKMElGTklRVElnDQpVMlZqZFhKbElGTmxjblpsY2lC

Not like this:

LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlFbERDQ0EzeWdBd0lCQWdJUUFmMmo2MjdL
ZGNpSVE0dHlTOCs4a1RBTkJna3Foa2lHOXcwQkFRc0ZBREJoDQpNUXN3Q1FZRFZRUUdFd0pWVXpF
Vk1CTUdBMVVFQ2hNTVJHbG5hVU5sY25RZ1NXNWpNUmt3RndZRFZRUUxFeEIzDQpkM2N1WkdsbmFX
"id_token token"
],
"application_type":"web",
"subject_type":"public",
"post_logout_redirect_uris":["https://cp-console.apps.test.ibm.com"],
"preauthorized_scope":"openid profile email general",
"introspect_tokens":true,
"trusted_uri_prefixes":["https://cp-console.apps.test.ibm.com/"],
"redirect_uris":["https://cp-console.apps.test.ibm.com/auth/liberty/callback","https://vm17-im-test.ibm.com/oidc_login/redirect_uri"]
}
Show more



1. Create a file named registration.json from the example template. Replace the values in the example template payload registration with the actual values based on your installation.



* YOUR_CLIENT_ID Your base64 encoded character string.
* YOUR_CLIENT_SECRET Your base64 encoded character string.

Note: The <YOUR_CLIENT_ID> and <YOUR_CLIENT_SECRET> need to be generated. The values can be any string, but normally a 32 character string that is base64 encoded is used. You can use BASE64 to encode your character string. For more information, see: [BASE64](https://www.base64encode.org/). Make a note of the values you generate for <YOUR_CLIENT_ID> and <YOUR_CLIENT_SECRET>. You will use the values in the next section to update the Apache configuration file.

Example command that uses base64 to encode a character string:


 Generate two encrypted streams from some longer-than-32-characters strings

echo There is a huge white elephant in LA zoo |base64

echo 12345678901234567890123456789012345 |base64
* UI
* Terraform







 Restricting users from creating API keys 

By default, all members of an account can create IBM Cloud® API keys. However, that access can be restricted so that only members with the correct access can create these user API keys by using the API key creation setting.

Restricting the ability to create API keys makes sense if you want users in your account to always log in interactively, meaning you don't want automation scripts to run that can log in users automatically by using an API key. For more information about API keys, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey).



 Enabling the API key creation setting 

To turn on the setting to restrict users from creating user API keys, you must have the following assigned access:



* An IAM policy with the Administrator, Operator, or Editor role on the [IAM Identity Service](https://cloud.ibm.com/docs/account?topic=account-account-servicesidentity-service-account-management).



If you turn on the API key creation setting, users in your account require specific access to create API keys, including the account owner. To restrict who can create API keys, use the following steps:

Enabling this setting affects only the creation of user API keys. It does not affect API keys for service IDs.



1. In the IBM Cloud console, go to Manage > Access (IAM), and select Settings.
2. In the Account section, enable the API key creation setting.
3. Click Yes to confirm.



Now that the setting is enabled to restrict users from creating API keys, you can assign the required access to enable specific users to continue creating user API keys. Remember, the account owner is also required to be assigned this explicit access.





 Enabling the API key creation setting by using Terraform 

If you turn on the API key creation setting, users in your account require specific access to create API keys, including the account owner.

To turn on the setting to restrict users from creating user API keys, you must have the following assigned access:
* UI
* CLI
* API
* Terraform







 Managing user API keys 

A federated user or non-federated user can create an API key to use in the CLI or as part of automation to log in as your user identity. You can use the console, CLI, or API to manage your IBM Cloud® API keys by listing your keys, creating keys, updating keys, or deleting keys.

The API key inherits all assigned access for the user identity for which it is created, and the access is not limited to just the account where the API key is created because it inherits any policies that are assigned to the user. So, if the user has access to resources from multiple accounts, then the API key inherits the access from all accounts. Therefore, it is possible that a user's API key can be used to generate a token and access resources that a user has access to outside of the account where the API key was created.

A suspended user in your account might generate an IAM token by using an API key that exists in a different account where the user isn't suspended to continue accessing resources in your account. To revoke all access for a user, remove them from your account or delete all access grants through policies, access groups, and trusted profiles. For more information, see [Updating a user's status](https://cloud.ibm.com/docs/account?topic=account-status) and [Removing users from an account](https://cloud.ibm.com/docs/account?topic=account-remove&interface=ui).

Because the API key that is associated with your user identity has all of the access you're entitled to across any account that you are a member of, you must be cautious with how you use your API key. For example, an IBM Cloud service might need to act on behalf of a user or access services that are not IAM-enabled, so the service might request a user API key. In these cases, it is recommended that you create an API key that is associated with a functional ID that is assigned the minimum level of access that is required to work with the service.

A functional ID is a user ID created to represent a program, application, or service.
<-- <ol> -->

1. From the menu bar, click Manage > Access (IAM).
2. Click the Users page and then select yourself.
3. In the API keys pane, click Create an IBM Cloud API key.
4. Enter a Name and Description for your API key and click Create.
5. Click Show to see the API key that was generated for you.
6. Copy the API key so that you can use it to retrieve your new IBM Cloud IAM access token.

<-- </ol> -->

<-- </ul> -->Use the following steps if you want to create an IBM Cloud IAM token or if you want to obtain a new refresh token.<-- <ol> -->1. Generate a new IBM Cloud IAM access token by using the refresh token or the IBM Cloud API key.
POST https://iam.cloud.ibm.com/identity/token

Header
: <-- <ul> -->

* Content-Type: application/x-www-form-urlencoded
* Authorization: Basic Yng6Yng=: Where Yng6Yng= equals the URL-encoded authorization for the username bx and the password bx.

<-- </ul> -->

Body when using the refresh token
: <-- <ul> -->

* grant_type: refresh_token
* response_type: cloud_iam uaa
* refresh_token: Your IBM Cloud IAM refresh token.
* uaa_client_ID: cf
* uaa_client_secret:
* bss_account: Your IBM Cloud account ID. Add the uaa_client_secret key with no value specified.

<-- </ul> -->

Body when using the IBM Cloud API key
: <-- <ul> -->

* grant_type: urn:ibm:params:oauth:grant-type:apikey
* response_type: cloud_iam uaa
For more information about licenses, contact the system administrator of the data source.







 What you need before you begin 

You must have the following information ready. If you don't know it, ask your Salesforce administrator to provide the information or consult the [Salesforce developer documentation](https://developer.salesforce.com/docs/).

Username
: The username of an account that has access to the Salesforce site. For example, jdoe@example.com

Password
: The password associated with the username. For example, myP@ssw0rd.

Service token
: A valid Salesforce security token. For example, mnaO8jsRET5CiJww9JnURlNN.

URL
: The URL of the Salesforce site that you want to crawl. For example, https://my.salesforce.com





 Connecting to the data source 

To configure the Salesforce data source, complete the following steps in Discovery:



1. From the navigation pane, choose Manage collections.
2. Click New collection.
3. Click Salesforce, and then click Next.
4. Add values to the following fields:



* Username
* Password plus service token

To form the password, concatenate the Password and Service token values that you noted earlier. For example, myP@ssw0rdmnaO8jsRET5CiJww9JnURlNN. The password and token values are never returned and are used only when credentials are created or modified.
* URL



Click Next.
5. Name the collection.
6. If the language of the documents on the site is not English, select the appropriate language.

For a list of supported languages, see [Language support](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-language-support).
7. Optional: Change the synchronization schedule.