vania-janet/multiturn-rag-retrieval-data huggingface dataset:
You can now use the updated certificates when you follow instructions in subsequent steps.

If you reach the enrollment limit for an identity, simply use the console to register a new user and enroll an identity and then use the generated certificate in subsequent steps.

If the CA admin identity expires, you are not able to update any of the identities in the CA table. And when you open the CA node, there is a message that indicates the users cannot be listed. To fix this problem, click Associated identity for root CA. In the side panel that opens, click the Enroll ID tab to enroll a new admin identity for the CA admin by providing the original Enroll ID and secret and a new display name for the identity, then click Associate identity. You can now proceed with the steps to enroll a new identity for other users in the table by clicking Enroll identity from their action menu.





 Step two: Update organization MSP 

If this is an MSP admin identity that was generated after Node OU support was enabled for the MSP, the admin role is inserted directly into the generated admin certificate, and therefore the MSP does not need to be updated. You can skip this step.

If this is an MSP admin identity, and the associated MSP Node OU support was disabled when the identity was originally enrolled, then you need to perform the following additional steps:

Before attempting these steps, be aware that these actions trigger a restart of the peer or ordering nodes that are configured with this MSP.



1. Open the Nodes tab in your console.
2. Locate the node tile that requires the admin certificate update. The MSP name is listed on the tile under the node name. Make a note of the MSP name.
3. Open the Organizations tab.
4. Locate the MSP tile for the organization MSP from step two and click the Export icon.
5. Open the downloaded MSP JSON file in a text editor.
6. Edit the admins element by appending the new base64-encoded certificate string that you generated in the previous section to the end of the list of comma-separated admin certificates. If the identity was enrolled from the console, ensure that the Root Certificate Authority was selected.
Step 4: Create your service ID 

After your programmatic name is review, you can create your service ID. A service ID is used to identify your service when you communicate with other IBM Cloud services, for example, when you submit metering usage data for your service. For more information, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceids&interface=ui).

You're also required to create an API key for your service ID. To create your API key, see [Creating an API key for a service ID](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeys&interface=uicreate_service_key).





 Step 5: Provide details for your product 

When your service is published in the catalog, it's represented by a catalog entry and a product page. The contents of your catalog entry include your company or product logo, and a short description. The contents of your product page include a list of features, a detailed description, a link to your product's warranted documentation, and a description of your customer support experience.



1. Click Product details, and enter the URL to your company or product logo, for example http://svgur.com/i/TTP.svg.
2. Add a company logo.
3. Provide a short description about your service.
4. From the Category list, select the option that best fits how users might use your product, for example, Databases. Categories are used to organize similar products in the catalog based on common solutions, function, or use.
5. Enter keywords that users might use when they search the catalog for your service.
6. Provide the URL to the end user license agreement (EULA) that users must agree with to use your product. Do not include billing, payment, or tax terms in this agreement.
7. Provide a list of features that highlights your service's attributes and benefits for users.

Use a descriptive title and 1 - 2 sentences for each feature. You want the information to be visually scannable for users.
8.
Users who create the client ID are automatically added to the owners list, and not able to remove themselves.
5. Add the redirect URL, and click Next. You can add more than one URL and use these as the redirect_uri in the upcoming tasks. The redirect_uri value refers to the redirect URL.
6. Save your credentials. Copy the password for your service that is generated along with the client ID. You are not able to retrieve your password later.

If you don't have your password, you can delete and re-create your previously created client ID to generate another one.
7. Click Done.









 Step 1: Finding the regional endpoint 

After you successfully generate your client ID, you can start developing the oAuth flow. First, find the IAM regional endpoint for UI login that is closer to your deployed application by calling the following endpoint:

https://iam.cloud.ibm.com/identity/.well-known/openid-configuration

See the following curl command as an example:

curl -X GET https://iam.cloud.ibm.com/identity/.well-known/openid-configuration

HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer": "https://iam.cloud.ibm.com/identity",
"authorization_endpoint": "https://iam-region2.cloud.ibm.com/identity/authorize",
"token_endpoint": "https://iam-region2.cloud.ibm.com/identity/token",
...
}

This request can be done when the application starts, and again if the authorization_endpoint fails. You can cache the authorization_endpoint value for a short amount of time, and refresh after the cache expires or an error occurs.





 Step 2: Redirecting users to your dashboard_url
By adding the customer_id in X-Watson-Metadata header, the request indicates that it contains data that belongs to this customer_id.





Optionally, you can include the customer_id field with the metadata multipart form part instead of including the X-Watson-Metadata header.

If you specify a customer_id in the metadata multipart form part and the X-Watson-Metadata header for the same document, then the customer_id in the X-Watson-Metadata header is used.

This example adds the customer_id to both the X-Watson-Metadata header and the metadata:

curl -k -u "apikey:$API_KEY" -H "x-watson-userinfo:instance-id=asdf" -H "x-watson-metadata:customer_id=customer_header_123" -H "x-watson-discovery-next:true" -F "file=@$FILENAME" -F "metadata={"customer_id": "new123"}" -X POST "$API_URL/v2/projects/$PROJECT_ID/collections/$COLLECTION_ID/documents?version=2020-03-08"

Example output:

{
"document_id":"8b152926-e9f5-4f34-940a-c02da7ef3af4",
"result_metadata":{
"collection_id":"24265c0b-2a55-3ccf-0000-017334467b6e"
},
"metadata":{
"date":1594319812384,
"parent_document_id":"8b152926-e9f5-4f34-940a-c02da7ef3af4",
"customer_id":"customer_header_123"
},
"extracted_metadata":{
"sha1":"CEC7C1D3423C7D4ED58FC448F52681ECA93CED8A",
"numPages":"1",
"filename":"Simple.pdf",
You can specify user tags for boot and data volumes when you create a virtual server instance. Run the instance-create command and specify user tags in the user_tags option. You can also edit the tags later or add more tags to the specified volume. For more information, see the [VPC CLI reference](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-reference&interface=ui).

In the example command,



* The boot volume is defined by the --boot-volume option that specifies the user tags env:test4 and env:dev4.
* The data volume attachment is defined by the --volume-attach option and specifies the same user tags.



You can see the user tags when you look at the details of the boot or data volume after the instance is created.

ibmcloud is instance-create my-vsi-4 my-vpc-2 us-south-1 bx2-2x8 cli-subnet-1 --image ibm-centos-7-9-minimal-amd64-6 --keys my-keys4 --boot-volume '{"name": "boot-vol-4", "volume": {"name": "my-boot-vol-4", "profile": {"name": "general-purpose"},"user_tags": ["env:test4", "env:dev4"]}}' --volume-attach '[{"name": "my-vol-att1", "volume": {"name":"my-vol-4", "profile": {"name": "general-purpose"}, "capacity": 10 ,"user_tags": "env:test4", "env:dev4"]}}]'

Creating instance my-vsi-4 under account vpcdemo1 as user myuser@mycompany.com...

ID efd06503-f514-4ea2-ba6c-2b9c715e6269
Name my-vsi-4
If you identify the user interaction with a user_id, it counts as one use. If you identify the user interaction with a session_id, then it counts as three uses (because there is a separate session that is created for each interaction).

Design any custom applications to capture a unique user_id or session_id and pass the information to Watson Assistant. Choose a non-human-identifiable ID that doesn't change throughout the customer lifecycle. For example, don't use a person's email address as the user ID. In fact, the user_id syntax must meet the requirements for header fields as defined in [RFC 7230](https://tools.ietf.org/html/rfc7230section-3.2).

The built-in integrations derive the user ID in the following ways:



* For Facebook integrations, the user_id property is set to the sender ID that Facebook provides in its payload.
* For Slack integrations, the user_id property is a concatenation of the team ID, such as T09LVDR7Y, and the member ID of the user, such has W4F8K9JNF. For example: T09LVDR7YW4F8K9JNF.
* For web chat, you can set the value of the user_id property.



Billing is managed per monthly active user per service instance. If a single user interacts with assistants that are hosted by different service instances that belong to the same plan, each interaction is treated as a separate use. You are billed for the user's interaction with each service instance separately.





 Test activity charges 

Test messages that you send from the Preview button are charged. For the preview, a random user_id is generated and stored in a cookie. The multiple interactions that a single tester has with the assistant embedded in the preview are recognized as coming from a single user and are charged accordingly. If you are doing your own test, running a scripted regression test for example, use a single user_id for all of the calls within your regression test. Other uses are flagged as abuse.





 Handling anonymous users
You need to have an access group to add users to it. For more information about access groups, see [Setting up access groups](https://cloud.ibm.com/docs/account?topic=account-groups). After you create the access group, complete the following steps to add users:



1. In the IBM Cloud console, go to Manage > Access (IAM), select Access groups and select the Group that you want to have access.
2. From the Users tab for your access group, click Add users.
3. Select the user that you want to add and click Add to group.







 Granting individual users access to cases 

Using access groups to assign the support center and user management services is the most efficient way for you to assign access, but you can also assign the same permissions to individual users. To assign permissions to an individual user, use the following steps:



1. In the IBM Cloud console, go to Manage > Access (IAM), and then select Users.
2. Select the user.
3. Select the Access tab, and click Assign access.
4. Select Support Center from the list of services and click Next.
5. Select any combination of roles to assign the wanted access and click Review.
6. Click Add, then click Assign from the Access summary section.
Once your users authenticate, you can authorize access to backend resources that your app uses.

App ID also helps you deliver tailored experiences for your users based on a variety of factors. In App ID you can store information about your users and let developers use this information for their apps. App ID is available for iOS, Android, and the web. And of course, it's built with open standards like OAuth 2.0 and OIDC. To get started, check out the App ID service in the IBM Cloud catalog.





 Reasons to use the service 

App ID helps developers to easily add authentication to their web and mobile apps with few lines of code, and secure their Cloud-native applications and services on IBM Cloud. By requiring users to sign in to your app, you can store user data such as app preferences, or information from public social profiles, and then leverage that data to customize each user's experience within the app. App ID provides a log-in framework for you, but you can also bring your own branded screens to use with Cloud Directory.



Table 1. Reasons to use the App ID service

 Scenario Solution 

 You need to add [authorization and authentication](https://cloud.ibm.com/docs/appid?topic=appid-key-concepts) to your mobile and web apps but don't have a background in security. App ID makes it easy to add an authentication step to your apps. You can add email or user name, social, or enterprise sign-in to your apps with APIs, SDKs, prebuilt UIs, or your own branded UIs. 
 You want to limit access to your apps and back-end resources. You can secure your apps, back-end resources, and APIs easily by using the standards-based authentication provided by App ID. 
 You want to build personalized app experiences for your users. With App ID, you can [store user data](https://cloud.ibm.com/docs/appid?topic=appid-profiles) such as app preferences or information from their public social profiles, and then use that data to customize each experience of your app. 
 You want to manage users in a scalable way.
* If you want a specific user that is associated with your account to be updated about the case, add the user by using Contact watchlist. For more information about assigning users access to your account, see [Adding users to your case management access group](https://cloud.ibm.com/docs/get-support?topic=get-support-accessadd-user-access-group).
* Select Email me updates about this case to receive support case notifications.



7. Click Next.
8. Review your case summary and click Submit case.

After you receive an email verification for the case that you submitted, follow the instructions that are included in the email for further communication on the issue.

After your support case is created, you can follow its progress on the [Manage cases page](https://cloud.ibm.com/unifiedsupport/cases).







 Supported file types for cases 

When you create a case, you can attach a file. The following file types are supported:

7z, ace, ams, arm, asp, bash, history, bkp, big, bmp, bz2, ca, ca-bundle, ca-crt, cabundle, cap, cer, cert, cfg, cnf, crt, csr, csv, dat, dbs, debug, dib, dmesg, dmp, doc, docx, dotx, dump, email, eml, emz, env, eps, error, evt, evtx, fragment, gif, gz, gz_aa, gz_ab, gz_ac, har, hosts, htaccess, html, iaf, ics, id, img, info, jpb, jpe, jpeg, jpg, key, lic, log, logsm lon02, lst, lzh, mai, md5, mib, mjpg, msg, mso, odp, ods, odt, oft, openssh, out, ovf, ovpn, p7b, p7s, pages, pcap, pcf, pcx, pdb, pem, pfx, pic, pix,
Log on to IBM Cloud Pak® for Security as a Service by using the deployment URL provided in your Welcome email.
5. From the IBM Cloud Pak® for Security as a Service Homepage, click Settings > Manage users.



1. From the Manage users page, click Add user.
2. In the Name or Email address field, enter or select the user's email address.
3. Click Add user.

Tip: You can create multiple users at the same time.
4. Select the newly create user and assign permissions. For more information about permissions, see Adding or removing users.





For more information about Getting started in SaaS, see [Getting started](https://www.ibm.com/docs/en/cloud-paks/cp-security/saas?topic=getting-started).
Get in touch directly with the development team on [Slack](https://www.ibm.com/cloud/blog/announcements/get-help-with-ibm-cloud-app-id-related-questions-on-slack)!

The App ID Identity and Access Istio adapter
: Centralize all your identity management in a single place with the App Identity and Access adapter. The adapter can be configured to work with any OIDC-compliant identity provider, which enables it to control authentication and authorization policies in all environments including both front and backend apps. And, it does it all without any change to your code or the need to redeploy your application. For more information, see [Securing multicloud apps with Istio](https://cloud.ibm.com/docs/appid?topic=appid-istio-adapter).

Access user profile information through the GUI
: View information about all your users that you can leverage to build personalized app experiences. For more information, see [Storing and accessing profiles](https://cloud.ibm.com/docs/appid?topic=appid-profiles).

Cloud Directory: Automatically associate users with a profile
: Automatically associate Cloud Directory users with an App ID profile as you create them. For more information, see [Managing users](https://cloud.ibm.com/docs/appid?topic=appid-cd-users).





 18 May 2019 

Cloud Directory: View user information
: View information about your Cloud Directory users that you can leverage to build personalized app experiences. For more information, see [Viewing user information](https://cloud.ibm.com/docs/appid?topic=appid-cd-userscd-user-info).





 24 April 2019 

Version 4 of the runtime APIs
: Update your apps! To further the standards on which App ID is based, we've made a few changes. With those changes, we were able to tighten interoperability within the OIDC workflow and broaden the frameworks that are able to use the service.
The customer ID is associated with the allowlisted callback URL or with the data that is sent with the individual recognition request.
* With requests to add corpora, custom words, or grammars to custom language models:



* POST /v1/customizations/{customization_id}/corpora/{corpus_name}
* POST /v1/customizations/{customization_id}/words
* PUT /v1/customizations/{customization_id}/words/{word_name}
* POST /v1/customizations/{customization_id}/grammars/{grammar_name}



The customer ID is associated with the corpora, custom words, or grammars that are added or updated by the request.
* With requests to add audio resources to custom acoustic models:



* POST /v1/acoustic_customizations/{customization_id}/audio/{audio_name}



The customer ID is associated with the audio resource that is added or updated by the request.







 Specify a customer ID example 

The following example associates the customer ID my_customer_ID with the data passed with a POST /v1/recognize request:

IBM Cloud

curl -X POST -u "apikey:{apikey}" --header "X-Watson-Metadata: customer_id=my_customer_ID" --header "Content-Type: audio/wav" --data-binary @audio.wav "{url}/v1/recognize"

IBM Cloud Pak for Data

curl -X POST --header "Authorization: Bearer {token}" --header "X-Watson-Metadata: customer_id=my_customer_ID" --header "Content-Type: audio/wav" --data-binary @audio.wav "{url}/v1/recognize"







 Deleting customer data 

To delete all data that is associated with a customer ID, use the DELETE /v1/user_data method. You pass the string customer_id={id} as a query parameter with the request.
Adding entities 

Entities represent information in the user input that is relevant to the user's purpose.

If intents represent verbs (the action a user wants to do), entities represent nouns (the object of, or the context for, that action). For example, when the intent is to get a weather forecast, the relevant location and date entities are required before the application can return an accurate forecast.

Recognizing entities in the user's input helps you to craft more useful, targeted responses. For example, you might have a buy_something intent. When a user makes a request that triggers the buy_something intent, the assistant's response should reflect an understanding of what the something is that the customer wants to buy. You can add a @product entity, and then use it to extract information from the user input about the product that the customer is interested in. (The @ prepended to the entity name helps to clearly identify it as an entity.)

Finally, you can add multiple responses to your dialog tree with wording that differs based on the @product value that is detected in the user's request.



 Entity evaluation overview 

Your assistant detects entities in the user input by using one of the following evaluation methods:



 Dictionary-based method 

Your assistant looks for terms in the user input that match the values, synonyms, or patterns you define for the entity.



* Synonym entity: You define a category of terms as an entity (color), and then one or more values in that category (blue). For each value you specify a bunch of synonyms (aqua, navy). You can also pick synonyms to add from recommendations made to you by Watson.

At run time, your assistant recognizes terms in the user input that exactly match the values or synonyms that you defined for the entity as mentions of that entity.
* Pattern entity: You define a category of terms as an entity (contact_info), and then one or more values in that category (email). For each value, you specify a regular expression that defines the textual pattern of mentions of that value type. For an email entity value, you might want to specify a regular expression that defines a text@text.com pattern.
olcAccess: {2}to * by dn="cn=Manager,dc=ibmlsf,dc=com" write by * read
Show more

Replace the {SSHA} value with the password hash that you generated in the previous step.
9. Apply the changes by running the following command:

ldapmodify -Y EXTERNAL -H ldapi:/// -f chdomain.ldif
10. Create a file that is named basedomain.ldif and add the following lines to it:

dn: dc=ibmlsf,dc=com
objectClass: top
objectClass: dcObject
objectclass: organization
o: WES Migration
dc: ibmlsf
dn: cn=Manager,dc=ibmlsf,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
dn: ou=People,dc=ibmlsf,dc=com
objectClass: organizationalUnit
ou: People
dn: ou=Group,dc=ibmlsf,dc=com
objectClass: organizationalUnit
ou: Group
Show more
11. Apply the changes that are made in the previous step by running the following command:

ldapadd -x -D cn=Manager,dc=ibmlsf,dc=com -W -f basedomain.ldif
12. Create a file that is named ldapuser.ldif by using an editor, such as VI, and add the following lines to it (replace with your own required domain name in the "dc=,dc=" section):

dn: uid=Lsfclusteruser,ou=People,dc=ibmlsf,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: Lsfclusteruser
sn: Linux
userPassword: {SSHA}+A6gC87JU5ugW6qthWL2HGYzsQIdN1EN
loginShell: /bin/bash
uidNumber: 1003
Importing users in smaller batches 

You can use the import API endpoint to import small groups of users. You can add up to only 50 users per request with the import API endpoint. To add all your users through a single request, use the [import/all](https://cloud.ibm.com/docs/appid?topic=appid-cd-userscd-import-all) API endpoint.



1. If your users are [assigned roles](https://cloud.ibm.com/docs/appid?topic=appid-access-control), be sure to create the roles and scopes in your new instance of App ID.

The roles and scopes must be created exactly as they were in the previous instance with the same spellings.
2. Users are imported with a new Cloud Directory identifier. If your app references the Cloud Directory identifier in any way, you can choose to create a custom attribute and adjust your application to call the attribute instead of the identifier directly.
3. Import the users to your new instance of the service.

curl -X POST 'https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/cloud_directory/import?encryption_secret=mySecret'
--header 'Content-Type: application/json'
--header 'Accept: application/json'
--header 'Authorization: Bearer <IAMToken>'
-d '{"users": [
{
"scimUser": {
"originalId": "3f3f6779-7978-4383-926f-a43aef3b724b",
"name": {
"givenName": "John",
"familyName": "Doe",
"formatted": "John Doe"
},
"displayName": "John Doe",
"emails":
{
"value": "user@example.com",
"primary": true
}
],