vania-janet/multiturn-rag-retrieval-data huggingface dataset:
fmt.Println(string(b))

const params = {
parent: parentCrn,
name: 'Example Account',
ownerIamId: enterpriseAccountIamId,
};

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





 Creating accounts by using Terraform 

Use the following steps to create accounts by using Terraform:



1. Create an argument in your main.tf file. The following example creates an account by using the ibm_enterprise_account 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_account" "enterprise_account" {
parent = "parent"
name = "name"
owner_iam_id = "owner_iam_id"
}

You can specify the ID of an account owner on the owner_iam_id option. For more information, see the argument reference details on the [Terraform Enterprise Management](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/enterprise_account) page.
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply
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 a service requires a user API key for interacting with other services or applications, use the functional ID user API key. By using the API key that is associated with the functional ID, you can provide only the access that is needed for that service. Sharing a real user ID API key with a service allows the service to access any resources that the user can access across multiple accounts. Sharing a real user ID API key is highly discouraged.

Only the user for which the API key is associated and an Administrator for the Identity Service can delete it. You can use the IBM Cloud API keys in the command-line interface (CLI) or as part of automation to log in as your user identity. You can also use IBM Cloud API keys to access classic infrastructure APIs.

For more information about using an API key associated with your user identity, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikeymanage-user-keys).





 Other types of API keys 

In addition to your IBM Cloud API keys, a couple of other types of API keys are available that you might use:



* Service ID API keys
* Classic infrastructure API keys
* Service-specific API keys



You can also use API keys that are associated with service IDs that you create. Service IDs are used to connect an application inside or outside of IBM Cloud to an IBM Cloud service. Service ID API keys inherit all access that is assigned to the specific service ID. 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).

[Classic infrastructure API keys](https://cloud.ibm.com/docs/account?topic=account-classic_keys) are used to call the APIs for classic infrastructure services.
Select the location where you want to create your SSH key. 
 Name A name is required for your SSH key. 
 Resource group Select a resource group for the SSH key. 
 Tags You can assign a user tag to the SSH key so that you can easily filter a list of SSH keys. For more information, see [Working with tags](https://cloud.ibm.com/docs/account?topic=account-tag&interface=ui). 
 Access management tags Access management tags help you apply flexible access policies on specific resources. For more information, see the [Controlling access to resources by using tags](https://cloud.ibm.com/docs/account?topic=account-access-tags-tutorial) UI tutorial. 
 SSH key type Select a key type for the SSH key. The default value is rsa. The ed25519 SSH key type can be used only to create instances if the operating system supports this key type. This key type can't be used with Windows or VMware images. 



3. Select Upload a public key.
4. Click Upload a public key file.
5. Select the public key file and click Open. The file extension, .pub, typically indicates which file contains the public key.
6. Optionally, click Get sample API call to get an API code with all your SSH key information that you can copy.
7. Click Create.



Use the following steps to import an SSH key by pasting in the public key material into the UI.



1. In [IBM Cloud console](https://cloud.ibm.com/login), go to menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > SSH keys.
2. Click Create and enter the information that is in Table 1.



Table 1. Creating an SSH key for VPC selections
Configuring with the GUI 



1. Sign in to your IBM Cloud account and navigate to your instance of App ID.
2. In the Manage tab, set Custom Identity Provider to On.
3. Register your public key with App ID.



1. Navigate to the Custom Identity Provider tab
2. Paste your public key in the Public Key box and click Save.









 Configuring with the API 

Register your key by making a PUT request to the [Management API endpoint](https://us-south.appid.cloud.ibm.com/swagger-ui//Management%20API%20-%20Identity%20Providers/mgmt.set_custom_idp).

Put <managementURI>/config/idps/custom
Content-Type: application/json
{
isActive: true,
config: {
publicKey: Your newline separated (n) PEM public key
}
}







 Testing your configuration 

After you configure your App ID instance with a valid public key, you can use the test application that is provided by the service to verify that your configuration is correctly set up. In the example app, you can see App ID access and identity token payloads that are returned during a standard sign-in flow.



1. From the Custom Identity Provider tab, click Test to open the test application.
2. Create an [example JWT](https://jwt.io/) following the custom identity [protocol](https://cloud.ibm.com/docs/appid?topic=appid-custom-authgenerating-jwts).
3. Paste your JWT into the box that is labeled JSON Web Token and click Test to execute a sample authentication.



If successful, you can now see the decoded App ID identity and access tokens that would be available to your application in a standard sign-in flow.





 Next steps
[Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/icon_hamburger.svg) > Resource list and clicking the name of the service that you're targeting. In the Details section, copy the CRN.



2. In the IBM Cloud console, click Manage > Access (IAM), and select Trusted profiles.
3. Click Create profile.
4. Define your profile by providing a name and a description, and click Continue.

In the description, provide a list of actions that are available for the trusted profile.
5. You can create the trusted profile before adding details by selecting Decide later. Or, establish trust by completing the following steps:



1. Select IBM Cloud® services.
2. Enter the CRN that service administrator provided to you.



6. Click Continue.
7. (Optional) [Assign access to the trusted profile](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profiletp-access).
8. Or, click Create without assigning any access.



IBM Cloud services are static identities that don't use conditions to establish trust. Instead, you establish trust by using the CRN to create a direct link with the trusted entity.





 Establishing trust with service IDs in the console 

You can use trusted profiles to give a service ID cross-account access and access to call classic infrastructure services. Complete the following steps to define how a service ID can access specific resources in your account:



1. Ask an administrator in the other account for the service ID value that identifies the service ID.

An administrator can find the service ID value by going to Manage > Access (IAM) > Service IDs, and selecting the service ID that you want to target. Click Details and copy the ID that begins with ServiceId.
2.
Create an [example JWT](https://jwt.io/) following the custom identity [protocol](https://cloud.ibm.com/docs/appid?topic=appid-custom-authgenerating-jwts).
3. Paste your JWT into the box that is labeled JSON Web Token and click Test to execute a sample authentication.



If successful, you can now see the decoded App ID identity and access tokens that would be available to your application in a standard sign-in flow.





 Next steps 

Now that your custom identity provider is configured, [add it to your application](https://cloud.ibm.com/docs/appid?topic=appid-custom-authcustom-auth)!
Separate the patterns with spaces. If you specify Login, it is disallowed for users whose primary group or supplementary group list matches one of the patterns. You can use "" and "?" can be used as wildcards in the patterns. Only group names are valid; a numerical group ID is not recognized. By default, Login is allowed for all groups.





 DenyUsers 

After this keyword, include a list of username patterns. Separate the patterns with spaces. If you specify Login, it is disallowed for usernames that match one of the patterns. You can use"" and "?" as wildcards in the patterns. Only usernames are valid; a numerical user ID is not recognized. By default, Login is allowed for all users. If the pattern takes the form USER@HOST, then USER and HOST are separately checked, restricting logins to particular users from particular hosts.







 Example 

In the following example, only two specific users, admin and user1 are allowed to log in to the server.

You can use a similar method to deny groups by using the keywords DenyGroups and DenyUsers.

AllowUsers admin user1

To prepare for future expansion of users, you can create a Group on the server that can log in to the server. You can add individual users as needed (replace username with the actual user):



1. In shell, add a user group, such as sshusers:

groupadd –r sshusers
2. In shell, add users to the group:

usermod –a –G sshusers admin

usermod -a -G sshusers user1
3. In the sshd_config file, give access to the sshusers group:

AllowGroups sshusers
4. Verify that sshd reads the new configuration without breaking:

/usr/sbin/sshd –t

echo $?

If you get a 0 following the echo $? command, the new configuration is correct.

You can also get error messages similar to the following examples:
7. If you already know your MQ Username and IBM Cloud API Key, you can skip to the [next section](https://cloud.ibm.com/docs/mqcloud?topic=mqcloud-mqoc_admin_mqcliexpconnect_mqoc_admin_mqcliexp) of this task. Otherwise, Click the Administration tab.

![Image showing the Administration tab](https://cloud.ibm.com/docs-content/v1/content/3a120b16db5fdc3e70d071af8a63ce5515c1b096/mqcloud/images/mqoc_administration_tab.png)
8. Make a note of your MQ Username for future use.



* Note that you can edit your MQ Username at any time by following the [Editing or removing the MQ username for an existing user or application](https://cloud.ibm.com/docs/services/mqcloud?topic=mqcloud-mqoc_administer_mq_username) guide.



9. If you do not already have an existing IBM Cloud API key:



* Click Create IBM Cloud API Key.
* Click Show to display the API key to copy and save it for later, or click Download to store the API key in a file.



* Note that the API key generated in these steps is used to authenticate with IBM Cloud as the user who created it. Therefore, it should not be shared with any other users and should be stored securely.
* An API key created through the IBM MQ service can be reset from the queue manager Administration tab.



* Click Close.









 Connect to your queue manager 



 Using MQ Explorer: 



1. Start IBM MQ Explorer.
2. In the 'MQ Explorer - Navigator' panel, expand IBM MQ.
3. Right click Queue Managers.
4. Click Add Remote Queue Manager....

!
* [Developing a finance application by using IBM Cloud](https://www.ibm.com/cloud/blog/developing-finance-application-using-ibm-cloud)
* [Apply end-to-end security to a cloud application](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-cloud-e2e-securitycloud-e2e-security)







 Integrating with your enterprise user directory 

Need help integrating with your enterprise apps? Don't worry! App ID can do that too.



* [Setting up IBM Cloud® App ID with your Azure Active Directory](https://www.ibm.com/cloud/blog/setting-ibm-cloud-app-id-azure-active-directory)
* [Setting up IBM Cloud® App ID with Ping One](https://www.ibm.com/cloud/blog/setting-ibm-cloud-app-id-ping-one)
* [Setting up IBM Cloud® App ID with your Active Directory Federation service](https://www.ibm.com/cloud/blog/setting-ibm-cloud-app-id-active-directory-federation-service)







 Custom sign-in experience 

Want to have a custom experience for your users? Not a problem.



* [Use your own branded UI for user sign-in with App ID](https://www.ibm.com/cloud/blog/use-branded-ui-user-sign-app-id)
* [Use your own UI and flows for user sign-up and sign-in with App ID](https://www.ibm.com/cloud/blog/use-ui-flows-user-sign-sign-app-id)
* [Use a custom login page with App ID](https://www.ibm.com/cloud/blog/custom-login-page-app-id-integration)
* [Use your own provider for mail sent with App ID](https://www.ibm.com/cloud/blog/use-ibm-cloud-app-id-and-your-email-provider-to-brand-mails-sent-to-app-users)
Make note of the Facebook application ID and secret in the Basic section of the Settings menu. These values are needed to configure your web project for authentication in your service dashboard.
3. From the products list, select Facebook Login.
4. Select the platform and enter the site URL.
5. On the Facebook Login settings page, enter the authorization server callback endpoint URL in the Valid OAuth redirect URIs field.
6. Click Save Changes.







 Configuring App ID for Facebook authentication 

When you have your Facebook app ID and secret, and your Meta for Developers app is configured to serve web clients, you can edit the Facebook authentication in your service dashboard.



1. From the Manage tab of your service dashboard, select Facebook and click Edit.
2. Enter the Facebook application ID and secret that you obtained from the Meta for Developers website.
3. Copy the URI that is in the Redirect URI for Meta for Developers field. Paste the URI into the Valid OAuth redirect URIs field in the Facebook Login Settings section of the Meta for Developers site.
4. Click Save.
5. Optional: For web apps, enter the redirect URL in the Web Application Redirect URLs field. This value is determined by the developer and used to access the redirect URL after the authorization process is completed. The URL must follow an http or https scheme. For a higher level of security, use an https scheme.









 Configuring Google 

You can configure the App ID service to use Google as an identity provider.



 Getting a client ID and secret 

Google documentation [link](https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid)

Create a project in the [Google Cloud Platform](https://cloud.google.com), configure the project to serve web clients, and obtain a client ID and secret.



1. Create a project.
2.
For more information, see [Creating an IBM Cloud API key](https://www.ibm.com/docs/en/app-connect/containers_cd?topic=servers-creating-cloud-api-key).







 Source server details 

After you mount your Object Storage bucket, you need to provide your source server details:



1. Enter the source server IP address or hostname (this is the MySQL database that needs to be migrated).
2. Enter the source server login credentials. The script needs to authenticate with the username and password. The user privileges should be equivalent to the root.







 Source server database details 



1. Enter the source server MySQL connection details (username for the MySQL application, which is root by default).
2. Enter your password for MySQL, which authenticates you to perform actions on the MySQL database that you want to migrate.
3. Enter the database name that you want to migrate.







 Target server details 

After you provide your source server and source server database details, you need to provide your target server details:



1. Enter the target server IP address or hostname (this is the target server where the MySQL database will be migrated).
2. Enter the target server login credentials. Similarly, for the source server, the script needs to be authenticated with the username and password. The user privilege should be equivalent to the root.







 Target server database details 



1. Enter the target server MySQL connection details (username for the MySQL application, which is root by default.
2. Enter your password for MySQL, which authenticates you to perform actions to restore the database.
3. Enter the source server database name.
4. Enter the target database name. By default, this fetches the database name from the source database name. If the you want to have a different database name for migration, then you can provide the input per your requirement.
5. After a successful database migration, you are prompted with a "complete" message.
Before you can manage user API keys by using Terraform, make sure that you have completed the following:



* Install the Terraform CLI and configure the IBM Cloud Provider plug-in for Terraform. For more information, see the tutorial for [Getting started with Terraform on IBM Cloud®](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started). The plug-in abstracts the IBM Cloud APIs that are used to complete this task.
* Create a Terraform configuration file that is named main.tf. In this file, you define resources by using HashiCorp Configuration Language. For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).







 Creating an API key by using Terraform 

Use the following steps to create access groups by using Terraform.



1. Create an argument in your main.tf file. The following example creates an access group by using the ibm_iam_api_key resource, where name is a unique name to identify the API key.

resource "ibm_iam_api_key" "iam_api_key" {
name = "test1234"
}

The description property is only available if a description is provided during API key creation. For more information, see the argument reference details on the [Terraform Identity and Access Management (IAM)](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/iam_api_key) page.
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1.
By default, the enterprise is created with the currently logged-in user in the following roles:



* The contact for the enterprise, which identifies a focal person to notify with enterprise-related concerns
* The owner of the enterprise account, which has full access to manage the enterprise account



You can specify the IBMid for a different user on the --primary-contact-id option. The same user is assigned to both roles.
3. Review the impact to your account, and confirm that you want to continue by entering y.

Account abcde12345fghij67890 will be incorporated into enterprise My new enterprise
(which cannot be undone). Do you want to proceed? [y/N]> y



After the enterprise is created, two new IDs are displayed. The first ID is associated with the enterprise, and the second ID identifies the enterprise account, which you use to manage the enterprise.

ID: 09876jihgf54321edcba
Enterprise Account ID: edcba12345jihgf67890

The account that you used to create the enterprise is now a part of the enterprise. Run the [ibmcloud enterprise accounts](https://cloud.ibm.com/docs/account?topic=cli-ibmcloud_enterpriseibmcloud_enterprise_accounts) command to view the two accounts in your enterprise: the enterprise account, and the account you used to create the enterprise.





 Creating an enterprise by using the API 

You can programmatically create an enterprise by calling the Enterprise Management API as shown in the following sample request. For detailed information about the API, see [Enterprise Management API](https://cloud.ibm.com/apidocs/enterprise-apis/enterprise).



* Curl
* Java
* Python
* Go
* Node



curl -X POST "https://enterprise.cloud.ibm.com/v1/enterprises
-H "Authorization: Bearer <IAM_Token>"
-H 'Content-Type: application/json'
-d '{
REGISTER EXTERNAL AUTHENTICATION SYSTEM 'IBMIAM' with 'PRODUCTION'
3. Create a user or users with the external authentication method set to IBMIAM.

CREATE USER USER AUTH EXTERNAL 'IBMIAM';

Example:

CREATE USER xyz@ibm.com AUTH EXTERNAL 'IBMIAM';
4. Verify whether the user was created successfully.

q

nzsql -u '"USER"' -pw PASSWORD

Example:

q

nzsql -u '"xyz@ibm.com"' -pw XXXXXXXXXXXXX
Welcome to nzsql, the IBM Netezza SQL interactive terminal.

Type: h for help with SQL commands
? for help on internal slash commands
g or terminate with semicolon to execute query
q to quit

SSL enabled connection. Cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, protocol: TLSv1.2

SYSTEM.ADMIN(xyz@ibm.com)=>
To configure document-level security, you need to collect the following information:

LDAP server URL
: The LDAP server URL to connect to. For example, ldap://<ldap_server>:<port>.

LDAP binding username
: The username to use to bind to the directory service. This user must have administrative access and be listed in the internal Domino LDAP directory.

LDAP binding user password
: The password that is associated with the user.

LDAP base DN
: The starting point for searching user entries in LDAP. For example, CN=Users,DC=example,DC=com.

LDAP user filter
: The filter to apply to searches for user entries in LDAP. If unspecified, the default value is (userPrincipalName={0}).

LDAP group filter
: The filter to apply to searches for group entries in LDAP.
* Before you can crawl servers by using the Domino Internet Inter-ORB Protocol (DIIOP) protocol, you must configure the HCL Notes server to use the protocol. The server that you want to crawl must be running the DIIOP and HTTP tasks.



To configure the HCL Notes server to use DIIOP, complete the following steps:



1. Configure the HCL Notes server document.



* In HCL Notes, open the server document on the HCL Notes server that you want to crawl. This document is stored in the Domino directory.
* On the Configuration page, expand the server section.
* On the Security page in the Programmability Restrictions section, specify the appropriate security restrictions for your environment in the following three fields:



* Run restricted Lotus Script/Java agents
* Run restricted Java/Javascript/COM
* Run unrestricted Java/Javascript/COM



For example, you might specify an asterisk () to allow unrestricted access by LotusScript/Java agents and specify usernames that are registered in the Domino directory for the Java/JavaScript/COM restrictions.