vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To import the identity, open the Wallet tab and click Add identity.
2. Give the identity a name.
3. Click Add certificate and browse to the .pem files for the organization admin identity certificate and private key.







 Step 5: Deploy a blockchain node 

You've gathered all the certificates, created and imported the MSP, and imported the organization admin identity, you are now ready to deploy a peer or ordering node. The process to deploy a peer and ordering node is slightly different:



 Deploy peer 



1. From the Nodes tab, click Add peer > Create peer.
2. Provide a name for your peer.
3. Under Advanced deployment options, check Use your own CA certificate and private key and click Next.
4. In the Certificate field, click Add certificate and browse to the peer enrollment certificate .pem file. This is certificate 1 in the Node certificates table.
5. In the Private key field, click Add certificate and browse to the peer enrollment private key .pem file. This is certificate 2 in the Node certificates table.
6. In the MSP drop-down list, select the MSP that you imported into the console.
7. Select a Fabric version for your peer and click Next.
8. Provide the TLS certificate and key for the node. In the Certificate field, click Add certificate and browse to the peer TLS certificate .pem file. This is certificate 3 in the Node certificates table.
9. In the Private key field, click Add certificate and browse to the peer TLS private key .pem file. This is certificate 4 in the Node certificates table. Click Next.
10. From the Peer administrator identity drop-down list, select the organization admin identity that you imported into the wallet.
11. Review the details on the Summary panel and click Add peer.







 Deploy ordering service 



1. From the Nodes tab, click Add ordering service > Create ordering service.
2. Provide a name for your ordering service and select the number of ordering nodes that you want to deploy.
3.
* Note: If you select this option, the initial access to the Appliance Administrative UI will redirect to the OIDC Identity Provider authentication screen.



6. In the Role Settings section, select the Get User Groups from External Authentication (HTTPd) setting.
7. Click Save.
8. Select Access Control, click Groups and make sure the user’s groups are created on the Appliance and appropriate roles are assigned to those groups. The user's groups to be added in Infrastructure management should have the same names as the groups defined in the LDAP server that is configured in the IBM Cloud Pak console.



1. Under the Access Control, click Groups.
2. Click Configuration, then Add a new Group.
3. Enter your existing LDAP group name in the Description field. For example, im_ldap_group.
4. Select the Role for this LDAP group. For example, select the EvmRole-super_administrator to map to this group. The Infrastructure management administrator can map to the roles that make sense for the user group.
5. Select My Company for Project/Tenant.
6. Click Add.



Note: Access control in Infrastructure management is based on group membership as roles are assigned to groups. When Infrastructure management is integrated with IBM Cloud Pak for Multicloud Management using single sign-on (SSO), it looks at the user’s group membership in the identity token and checks if that group exists in Infrastructure management. If the group doesn't exist, then access is denied. You must create at least one group with the role EvmRole-super_administrator and assign one user to this group. This user will be the Admin user for Infrastructure management and referred to as IM_ADMIN_LDAP_USER. The IM_ADMIN_LDAP_USER must be a member of the LDAP group with the role EvmRole-super_administrator in Infrastructure management.

Important: You must create the groups in Infrastructure management that match your existing LDAP groups by name, and assign the groups account roles.
[Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 
 Google ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 
 SAML ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 
 Custom ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) 







 How is Cloud Directory handled? 

To ensure the integrity of a future user, Cloud Directory places extra requirements on preregistration.



* You must use an email, not a user name, to add the user. If you don't have any users yet, switch to email and password mode to add future users. If you do have users, you must wait until the user has signed in to assign custom attributes.
* The user must confirm their identity through verification. When you add a future user with specific attributes, those attributes are intended for that person. Any user that signs in by using an email that is registered to a future user must verify their email address before they are granted access to your app. To complete the verification requirements, you can send an email to have the user verify or manually verify their address on their behalf. To allow for self-verification, set Email verification to On in the Cloud Directory tab of the service dashboard. This sends an email to the user to request verification on their initial sign-in. To verify users manually, you must be an administrator.
NSX-T administration interface identity and access management 

The following main principles or requirements apply:



*  Infrastructure Admin has execute and full access to all components.
*  Auditor has read-only access to all components.





  NSX-T role mapping 



Table 1. NSX-T role mapping

 VMware NSX-T™ component   Auditor  Infrastructure admin 

 Controllers               Read     Full                 
 Transport Nodes           Read     Full                 
 Edge Nodes                Read     Full                 
 Segments - VLAN           Read     Full                 
 Segments - Overlay        Read     Full                 
 T0 - Tenant               Read     Full                 
 T0 - Transit              Read     Full                 
 T0 - Management           Read     Full                 
 T1s - Tenant              Read     Full                 
 T1s - Services            Read     Full                 
 T1s - Management          Read     Full                 



The roles and privileges for load balancing, firewall rules, and VPN services follow the T0/T1 roles and privileges.





  NSX-T roles 

NSX-T Data Center has the following built-in roles. You cannot add any new roles.



*  Enterprise administrator
*  Auditor
*  Network engineer
*  Network operations
*  Security engineer
*  Security operations
*  Load balancer administrator
*  Load balancer auditor
*  VPN administrator
*  Guest introspection administrator
*  Network introspection administrator







  NSX-T user interface user IDs 



Table 2. NSX-T user IDs

 User             User ID             Description                                                                                                                                                                                                                                                                              

 Privileged user  admin               Used post-deployment to manage NSX VTEP IP addresses and to manage host and cluster configuration when hosts and clusters are added and removed. Also used to manage ESG configuration for services that require public network access for licensing, activation, or usage reporting.    
 IBM automation   automation_admin    Automation account used by IBM. It uses the principle identity functions to create configuration and protect it with a certificate.                                                                                                                                                      



For more information, see the [VMware documentation - RBAC for NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/administration/GUID-26C44DE8-1854-4B06-B6DA-A2FD426CDF44.html).





  Related links 



*  [IBM Cloud compliance programs](https://www.ibm.com/cloud/compliance)
*  [IBM Cloud Hyper Protect Crypto Services API](https://cloud.ibm.com/apidocs/hs-crypto)
Mapping IBM Cloud IAM concepts to other cloud providers 

Identity and access management is used to securely authenticate users and provide access to cloud resources. While IAM across cloud providers is a consistent way of securing authentication and access, the concepts within each cloud provider and how they apply might differ. Review the following information in the table to learn more about how concepts in IBM Cloud IAM relate or compare to those of other cloud providers to help you onboard smoothly with IBM Cloud.



 Comparing IAM concepts 

The following mappings of IBM Cloud IAM concepts to those of other cloud providers, such as Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure, might not be an exact one-to-one match. However, if you are familiar with a particular concept within another provider, this mapping is intended to help you find the closest related concept in IBM Cloud.



Table 1. IBM Cloud IAM concept comparison
The first column is IBM Cloud IAM concept. Then, each of the following columns has details as that concept relates the specific cloud provider that is listed in the column header.

 IBM Cloud concept IBM Cloud description AWS Azure Google Cloud Platform 

 Identities Users and service IDs Users, groups, and roles User, group, service principal, managed identity User accounts and service accounts. Supported identity types: Google Account, Service account, Google group, G Suite domain, Cloud Identity domain 
 Users Managed outside IAM. Users are uniquely identified in IBM Cloud with the iam_id value, but can come from IBMid, App ID, or SoftLayer Managed in IAM. Identity federated to external identity management system. Managed in Active Directory Managed outside IAM. Identity federated to external identity management system. 
 Service IDs An ID for an app or service. Roles that are assigned to an app User-assigned identity Service accounts 
 API key A credential that is used for a user or service ID Access Key api-key API key 
 Access groups A way to organize users and service IDs where all members of the group are assigned the same access. Groups, roles Active Directory groups Google Groups 
 Trusted profiles A way to assign access to federated users based on SAML attributes or for all applications running in a compute resource without the need of managing and rotating credentials. Roles Managed identity Workload identity
For more information about time-based conditions for access policies, see [Conditions in access policies](https://cloud.ibm.com/docs/account?topic=account-iam-condition-properties&interface=uipolicy-condition-properties).





 Creating a recurring time-based condition 

You can assign recurring access at a weekly cadence. You might want to give users access to account resources during only their working hours.

Complete the following steps to assign an access policy with a recurring time-based condition:



1. In the IBM Cloud console, go to Manage > Access (IAM)
2. Select Users, Trusted profiles, Service IDs, or Access groups, depending on the entity to which you want to assign access.
3. Click the identity's name from the list and go to Access.
4. Click Assign access.
5. Select a service and click Next.



* If you want the user to be able to create any service, select All Identity and Access enabled services.
* If you want to assign the user access to a specific service, select it from the list.



6. Select the resource that you want to assign the user access to, or select All resources. Click Next.
7. (Optional) Select a resource group access role. Click Next.
8. Select any combination of service access and platform access roles, and click Next.
9. Click Add condition and select Weekly.
10. Select the time zone for the conditional policy.



As an example, let's say that you're creating a conditional policy for a developer that is based in Dublin. In this case, select UTC+1 so that the date and time range that you select next is enforced at the right time for that location.



1. Select the days of the week that you want the condition to grant access.



* (Optional) Set the All day toggle to No to specify a timeframe for the days that you select.



2. Click Create.
3. Click Review.
4. Click Add to add your policy configuration to your policy summary.
5. Click Assign.
CA affiliations are defined by using the Fabric CA [Affiliation Command](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/clientcli.htmlaffiliation-command). The default affiliation that is available when you clear the Use root affiliation checkbox is ibp.
* Maximum Enrollments: Optionally, enter the number of times that you can enroll or generate certificates by using this identity. Specifying a limited number of enrollments helps protect the security of your nodes and applications. It defaults to unlimited enrollments.
* Attributes: Optionally, you can specify any [attribute-based access control](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.htmlattribute-based-access-control) attributes for the user. For example, you can use this section to [create another CA admin](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-ca-identity) with authority to register and enroll new identities. You can see a full list of available Fabric CA attributes in the [Registering a new identity](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/users-guide.htmlregistering-a-new-identity) section of the Fabric CA users guide.



Click the Register user button on the CA overview panel to create a new user. Be sure that you have [set the identity](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-ca-identity) to a CA admin that has the ability to register new users before you attempt this task. In general, this is your admin user. If the button is gray, you have either not set an identity, or that the identity cannot create new identities.

Clicking Register user opens a series of side panels:



1. On the first side panel, enter the Enroll ID and Enroll Secret of the new identity.
* UI
* CLI
* API
* Terraform







 Using toolchains 

Open toolchains are available on IBM Cloud®. You can use a toolchain to be productive in your daily development, deployment, and operations work. After you set up a toolchain, you can add, delete, or configure tool integrations and manage access to the toolchain. For more information about working with tool integrations, see [Working with tool integrations](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-integrations).



 Managing access to toolchains 

You can use the Identity and Access Management (IAM) service to manage user access to toolchains in resource groups. For more information about managing access control with IAM, see [Managing user access to toolchains in resource groups](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-security).

Users with access to toolchains might be counted as authorized users of the IBM Cloud® Continuous Delivery service. For more information about how authorized users are counted, see [Plan limitations and usage](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-limitations_usage).





 Organizing toolchains 

You can add tags to your toolchains to organize them and easily find them later. A tag is a label that you assign to a toolchain for easy filtering of toolchains in your toolchains list.



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg), and select DevOps.
2. On the Toolchains page, locate the toolchain that you want to add a tag to and click Add tags.
3.
"picture": "String",
"gender": "String",

// Custom Scopes to add to access token (optional)
scope="custom_scope1 custom_scope2"

// Other custom claims (optional)
role="admin"
}



Table 1. JWS fields

 Field Description 

 iss Should contain a reference to your identity provider. 
 aud The OAuth server URL. Format: https://<region>.appid.cloud.ibm.com/oauth/v4/<tenantID>. 
 exp The length of time that the token is valid. For security reasons, it should have a short life span and be specific. 
 sub The unique user ID that is provided by the identity provider. 
 Normalized claims All [normalized claims](https://cloud.ibm.com/docs/appid?topic=appid-tokens) are provided in the identity token that is returned in response to this request. More custom claims can be found by using the [/userinfo endpoint](https://cloud.ibm.com/docs/appid?topic=appid-profiles). 
 Scope By default, all App ID tokens contain a group of preset scopes. You can request extra scopes by doing one of the following:<br><br><br><br> * Specify the scope in the scope field of your JWS token.<br> * Specify the scope through the URL-form scopes parameter of the /token request.<br><br><br> 









 Retrieving App ID tokens 

To create the bridge between your custom provider and App ID, you need to have App ID tokens. To obtain service tokens, exchange your verified user information by using the [/token endpoint](https://us-south.appid.cloud.ibm.com/swagger-ui//Authorization_Server_V4/token).

Post /token
Content-Type: application/x-www-from-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
If a user leaves your company, you can delete the user's corporate identity in your directory, which revokes access to IBM Cloud.





 Functional IDs 

Functional IDs are most commonly used when an application or service needs a digital identity and access to IAM-enabled resources or classic infrastructure resources. Some services require a functional ID when you create service instances, for example the Kubernetes Service.

A functional ID is a type of user ID that exists in your Identity Provider's (IdP) user directory, but it's not tied to a specific user. To create a functional ID, you must create a new user in the user directory and invite them to your IBM Cloud account.

The functional ID is used to create service instances, like Kubernetes Service clusters. This way, instances aren't linked to a specific person that might leave the company, which would leave the instance without an owner. Generally, functional IDs can do more in IBM Cloud than a service ID. For example, functional IDs, like user IDs, can be granted access to services and applications through access policies.

IBM Cloud API keys for users can be created and associated with a functional ID. If a service requires a user API key for interacting with other services or applications, use the functional ID 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.

If you're using a functional ID as the account owner, instead consider [Setting an alternative account owner](https://cloud.ibm.com/docs/account?topic=account-classic-infra-owner&interface=ui). This is available only for classic infrastructure accounts.







 Service IDs 

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
For more information about autoupdates, see [OnDemand ALB update feature on Kubernetes Service](https://www.ibm.com/cloud/blog/on-demand-alb-update-feature-on-ibm-cloud-kubernetes-service).





 Adding redirect URLs 

A redirect URL is the callback endpoint of your app; the location where a user is sent after successfully signing in or out of your app. To prevent phishing attacks, App ID validates requested URLs against an allowlist of redirect URLs that you add to the service. By adding a URL to your allowlist, you give App ID permission to forward your users to that location. [Learn more about redirect URIs](https://cloud.ibm.com/docs/appid?topic=appid-managing-idpadd-redirect-uri).



1. In the IBM Cloud console, select your instance of App ID from your resource list.
2. Navigate to the Manage authentication page of your instance of App ID.
3. In the Identity providers tab, be sure that an identity provider is set to on.

If no provider is selected, the user is not authenticated, but is still issued an access token for anonymous access to the app.
4. In the Authentication settings tab, add your redirect URLs and click the + symbol to save your changes. Your redirect URL should be formatted similarly to the following example:

https://<hostname>/oauth2-<AppIDServiceInstanceName>/callback



* Custom domain:

A URL that is registered with a custom domain might look like: http://mydomain.net/myapp2path/oauth2-myappid/callback. If the apps that you want to expose are within the same cluster but in different namespaces, you can use a wildcard to specify all of them. This can be helpful during development, but it is recommended that you exercise caution when you use wildcards in production.
For a list of supported languages, see [Language support](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-language-support).
6. Optional: Change the synchronization schedule.

For more information, see [Crawl schedule options](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-collectionscrawlschedule).
7. In the Enter your credentials section, complete the following fields:

Username
: The username of the SharePoint user with access to all sites and lists that need to be crawled and indexed.

Password
: The password of the SharePoint user.

This value is never returned and is only used when you create or modify credentials.
8. Optional: If you want to use Security Assertion Mark-up Language (SAML) claims-based authentication, set the Enable SAML authentication switch to On. Otherwise, Windows NT LAN Manager (NTLM) authentication is used. Add values to the following fields:

Identity Provider endpoint
: The URL of the Identity Provider endpoint, for example https://adfs.server.example.com/adfs/services/trust/2005/UsernameMixed.

Relying Party endpoint
: Optional. The URL of the Relying Party Trust endpoint. If unspecified, the following value is used: https://<sharepoint_server>:<port>/_trust/.

Relying Party Trust identifier
: The URL of the Relying Party Trust identifier, for example urn:sharepoint:sample. If unspecified, the following value is used: https://<sharepoint_server>:<port>/_trust/. This feature is available in the 2013, 2016, and 2019 versions.
9. In the Specify what you want to crawl section, add the SharePoint web service URL to the Web Application Url field. For example, https://<host>:<port>.
10.