vania-janet/multiturn-rag-retrieval-data huggingface dataset:
6. Click Add to add your policy configuration to your policy summary.
7. Click Assign to assign all added access to your access group.









 Step 2: Invite users 

You can invite one or multiple users in a single invite. If you invite multiple users in one invitation, the same access is assigned to each user. However, you can invite users to your account with no access, and assign them access later.



1. In the IBM Cloud console, go to Manage > Access (IAM), and select Users.
2. Click Invite users. Specify the email addresses of the users. If you are inviting more than one user with a single invitation, they are all assigned the same access.
3. Add one or more of the access options that you manage. You must assign at least one access option. For any access options that you don't add and configure, the default value of No access is assigned. Depending on the options that you are authorized to manage, you can assign the following types of access:



* Access groups: Click Add for each access group that you want the users to belong to.
* Access policy: Assign individual IAM access policies or classic infrastructure permissions.



* Select Classic infrastructure, and then select from the three permission sets.
* Select a group of services like All Identity and Access enabled services, All Account Management services, and All IAM Access Management services, or select a specific service. Next, you can scope the access to the entire account or just one resource group. Then, select all roles that apply. To view what actions are mapped to each role, click the numbers listed next to each role.

Some services support the use of advanced operators to grant access to resources that satisfy specific naming conventions. See [Assigning access by using wildcard policies](https://cloud.ibm.com/docs/account?topic=account-wildcard) for more information.





4. Then, select all roles that apply.
5. Select Add to save the access assignment to the invitation.
6. After you add all the necessary access assignments, click Invite.
When the CA is first deployed (or when the CA is otherwise unavailable), the box in the tile for the CA will be gray box. When the CA has successfully deployed and is running, this box will be green, indicating that it is "Running" and can be operated from the console. Before proceeding with the steps below, you must wait until the CA status is "Running". If the gray box stops blinking, you can try reloading the page in your browser to refresh the status.

Once the CA is running, as indicated by the green box in the tile, complete the following steps:



1. Click the Org2 CA tile in the Nodes tab. Then click Associate identity on the CA overview panel.
2. On the side panel that opens, provide an Enroll ID of admin and an Enroll secret of adminpw. For the Identity display name, you can use the default value of Org2 CA Admin.
3. Click Associate identity to add the identity into your console Wallet and associate the admin identity with your CA.



After setting the CA admin identity, you will be able to see the table of registered users in the CA overview panel.

Task: Associate identity



Table 2. Associate the CA admin identity

 Field Display name Enroll ID Secret 

 Enroll ID Org2 CA Admin admin adminpw 



You can view the CA admin identity in your console wallet by clicking on the Wallet in the left navigation. Click the identity to view the certificate and private key of the CA admin. The identity is not stored in your console or managed by IBM. It is only stored in local browser storage. If you change browsers, you will need to import this identity into your Wallet to be able to operate the CA. Click Export identity to download the certificate and private key.

Task: Check your Wallet



Table 3. Check your Wallet

 Field Display name Description 

 Identity Org2 CA Admin Org2 CA admin identity 







 Using your CA to register identities 

Each node or application that you want to create needs certificates and private keys to participate in the blockchain network. You also need to create admin identities for these nodes so that you can manage them from the console.
The values that are shown in the example are required, but you can choose to include more information as shown in the table.

"config": {
"authnContext": {
"class": [
"urn:oasis:names:tc:SAML:2.0:ac:classes:YourChosenClassValue",
"urn:oasis:names:tc:SAML:2.0:ac:classes:YourOtherChosenClassValue"
],
"comparison": "sampleComparisonValue"
},
"idpInitEnabled": true,
"idpRedirectUrl": "https://example.com/redirect/endpoint",
"entityID": "https://example.com/saml2/metadata/706634",
"signInUrl": "https://example.com/saml2/sso-redirect/706634",
"certificates": [
"primary-certificate-example-pem-format"
"secondary-certificate-example-pem-format"
],
"displayName": "my saml example",
"signRequest": true ,
"encryptResponse": true
}



Table 3. SAML configuration variables

 Variable Description 

 signInUrl The URL that the user is redirected to for authentication. It is hosted by your SAML identity provider. 
 entityID The globally unique name for a SAML identity provider. 
 displayName The name that you assign to your SAML configuration. 
 primary-certificate-example-pem-format The certificate that is issued by your SAML identity provider. It is used for signing and validating SAML assertions. All providers are different, but you might be able to download the signing certificate from your identity provider. The certificate must be in .pem format. 
 DefaultRelayState The initial value for RelayState. This variable is configured in your identity provider's settings.
* Proxy endpoint: ClusterIP address that is generated for the HSM when the HSM proxy is configured.
* Label: Corresponds to the HSM Partition.
* PIN: The PIN associated with the HSM slot.



After HSM is configured for a node, the HSM becomes the cryptographic service provider for the node. When the HSM is subsequently used to generate and store a node's private key, and the node identity is exported or stored in the wallet, the private key is not visible.

For more information about how to deploy the HSM proxy and use HSM with a CA, peer, or ordering node, see [Configuring a node to use HSM](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-adv-deploymentibp-console-adv-deployment-cfg-hsm)





 Associating identities 

You need to provide the signing certificate of your organization and node admins [to your organization MSP definition](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-organizationsconsole-organizations-create-msp). The nodes or channels that are created by the console uses the certificates from the MSP definition to check who is a valid administrator. As a result, the same signing certificate and private key that you used to add an admin cert to the MSP definition needs to be stored inside your console wallet.

When you use the console to create an orderer or peer, you will encounter an Associate identity panel. Select an identity in the wallet whose certificate is also inside your organization MSP definition. You will also need to select an admin identity in the Associate identity section when you create or edit a channel. This allows your console to know which identity to use when it communicates with your peers, orderers, and ordering service consortium. The identity that is currently associated with a peer or ordering service is visible on the left side of the node panel, below the name, Node location, and Fabric version.





 Viewing the contents of a signing certificate
Edit the example JSON override file by providing the root CA TLS signing cert and the intermediate CA identity enroll id and secrets to the JSON override file.
* [Part Three: Actions you perform on the intermediate CA](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-icaibp-ica-part-three)



1. Create a new CA which will serve as the intermediate CA.
2. Provide the intermediate CA admin enroll ID and secret that you registered with the root CA.
3. Provide the CA JSON override file.





After completing these steps, when you create organization MSPs for your peers or orderers, you can point to the intermediate CA instead of the root CA.

This process can be performed using the console or the APIs, if you are an experienced API user. The overall process is the same regardless of which approach you choose. For clarity, this tutorial uses the console.





 Part One: Actions you perform from the root CA 



1. Deploy a root CA. Before you can deploy an intermediate CA, a root CA must already exist in your IBM Blockchain instance. See the [Build a network](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network-create-CA-org1CA) tutorial for instructions on how to create a CA.
2. Register the intermediate CA admin identity with the root CA. In order for an intermediate CA to be able to register and enroll identities, the intermediate CA admin identity must be registered with the root CA.



* Click the root CA tile to open it and click Register user.
* Enter the enroll ID and secret that you will use for the intermediate CA admin identity. For purposes of this tutorial we will use icaadmin and icaadminpw, but you can use any values suitable for your use case.
* Leave the identity type as client and optionally specify a value for maximum enrollments if you want to limit the number of times you can generate certificates for this admin identity.
To learn more about peers specifically, check out [this document focusing just on peers](https://hyperledger-fabric.readthedocs.io/en/release-1.4/peers/peers.html) from the Fabric community documentation.





 Certificate Authority 

As a platform for permissioned blockchain networks, Hyperledger Fabric includes a modular Certificate Authority (CA) component for managing the network identities of all member organizations and their users. The requirement for a permissioned identity for every user enables ACL-based control over network activity, and guarantees that every transaction is ultimately traceable to a registered user.



* The CA issues a root certificate (rootCert) to each member (organization or individual) that is authorized to join the network.
* The CA also issues an enrollment certificate (eCert) to each member component, server-side applications and occasionally users.
* Each enrolled user is also granted an allocation of transaction certificates (tCerts). Each tCert authorizes one network transaction.



This certificate-based control over network membership and actions enables members to restrict access to private and confidential channels, applications, and data, by specific user identities.

For more information about the Hyperledger Fabric Certificate Authority component, see [Fabric CA User’s Guide](https://hyperledger-fabric-ca.readthedocs.io/en/release-1.4/).





 Membership Service Provider 

Hyperledger Fabric includes a Membership Service Provider (MSP) component to offer an abstraction of all cryptographic mechanisms and protocols behind issuing and validating certificates, and user authentication. The MSP is installed on each channel peer to ensure that transaction requests that are issued to the peer originate from an authenticated and authorized user identity.

For more information about the Hyperledger Fabric Membership Services Provider component, see [Membership](https://hyperledger-fabric.readthedocs.io/en/release-1.4/membership/membership.html) in the [Hyperledger Fabric documentation](https://hyperledger-fabric.readthedocs.io/en/release-1.4/).





 Ordering service 

In other distributed blockchains, such as Ethereum and Bitcoin, there is no central authority that orders transactions and sends them out to peers.
This option is used only when you create a Subscription to a Configuration using the Direct Upload strategy. To list versions in your configuration, run ibmcloud sat config get --config <configuration_name_or_ID>.

-q
: Optional. Do not show the message of the day or update reminders.





 Example 

ibmcloud sat subscription create --name myapp_prod_subscription --group mygroup --config myapp_prod --version 1.0







 ibmcloud sat subscription get 

Get the details of a subscription, such as the Satellite configuration that the subscription is for or the registered clusters that are subscribed.

ibmcloud sat subscription get --subscription SUBSCRIPTION [--output JSON] [-q]



 Minimum required permissions 

IBM Cloud IAM Viewer platform role for the Subscription resource in Satellite. For more information, see [Checking user permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-accesschecking-perms).





 Command options 

--subscription SUBSCRIPTION
: Required. The name or ID of your subscription. To list subscriptions in your IBM Cloud account, run ibmcloud sat subscription ls.

--output JSON
: Optional. Displays the command output in JSON format.

-q
: Optional. Do not show the message of the day or update reminders.





 Example 

ibmcloud sat subscription get --subscription myapp_prod_subscription







 ibmcloud sat subscription identity set 

Update a Satellite subscription to use your identity to manage resources.

ibmcloud sat subscription identity set --subscription SUBSCRIPTION [-f] [-q]



 Minimum required permissions 

IBM Cloud IAM Editor platform role for the Subscription resource in Satellite. For more information, see [Checking user permissions](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-accesschecking-perms).





 Command options 

--subscription SUBSCRIPTION
: Required. The name or ID of your subscription.
Enabling one-time passcode MFA for a user 

As an Administrator on the IAM Identity Service or All IAM Account Management service, you can enable the multifactor authentication (MFA) option that prompts a user for a time-based one-time passcode (TOTP) at login. This type of legacy account-based MFA is required only for the account where the setting is enabled and is available only for accounts with classic infrastructure.

For more information about your MFA options, see [Types of multifactor authentication](https://cloud.ibm.com/docs/account?topic=account-types).



 Before you begin 

If you have any of the following access, you can update this setting for other users in your account:



* Administrator on the IAM Identity Service or All IAM Account Management services
* You are an ancestor in the classic infrastructure hierarchy for the user and you have the Manage users classic infrastructure permission assigned



To turn on this MFA option for a user, they must first set up TOTP. For more information, see [Setting up TOTP](https://cloud.ibm.com/docs/account?topic=account-totptotp-setup).





 Setting up TOTP 

Users can set up TOTP for extra authentication at login. You must set up your TOTP before you or administrator can enable this MFA requirement for you.

To set up TOTP, complete the following steps:



1. From the console, go to Go to Avatar icon ![Avatar icon](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/icons/i-avatar-icon.svg) > Profile and settings, and select Login settings.
2. In the Time-based one-time passcode authentication seciton, click Set up.
3. Scan the QR code with an authentication app on your device.
4. Click OK when you're finished.



To remove your TOTP, click Remove.





 Enabling TOTP for a user
In clusters two and three, [import the CA JSON file](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-import-nodesibp-console-import-ca) that you exported from cluster one.
2. If you will need to use the CA to register other identities, you need to open the imported CA and associate the CA administrator enroll ID and secret that you used when you deployed the CA on cluster one.
3. Import the peer organization MSP definition JSON file that you exported from cluster one.



* In the Organizations tab click Import MSP definition.
* Click Add file to upload the JSON file.
* Click I have an administrator identity for the MSP definition checkbox to allow you to use this MSP definition when you create new peers in other zones.
* Click Import MSP definition.



4. Import the organization admin identity JSON file that you exported from cluster one into the console wallet on clusters two and three.
5. In clusters two and three, [import the ordering service JSON file](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-join-networkibp-console-join-network-import-remote-orderer) to your console.







 Step four: Create new peers in cluster two and three and join a channel 



1. In clusters two and three, use the CA to register a new peer user, following the same steps that you took when you registered the peer identity in cluster one. You only need to create the peer users, you do not need to re-create the organization admin identity because you will import that in the next step.
2. Create new peers, by using the CA you that imported from cluster one as the peer's CA. Use the peer organization MSP that you imported from cluster one as the peer organization MSP definition.
3. In cluster two and three, you can now repeat the steps that you ran to join the peers to the same channel as the peer in cluster one.
4. After you install the smart contract on these redundant peers, they are able to transact and query the ledger.
Creating a project 

In a

project, you can add deployable architectures from the catalog and customize their configuration. Deploying a configuration from a project groups resources based on the configuration that you deployed.

You can create a project by going to the Navigation menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/icons/icon_hamburger.svg) and selecting [Projects](https://cloud.ibm.com/projects/) or from a deployable architecture in the [catalog](https://cloud.ibm.com/catalog/). Projects can also be created by using the [Project API](https://cloud.ibm.com/apidocs/projects).



 Before you begin 

Resources are created in the project account for the user. You must have permission to create a project and permission to create the project tooling resources within the account. Make sure that you have the following access:



* The Editor role on the IBM Cloud Projects service.
* The Editor and Manager role on the IBM Cloud® Schematics service
* The Viewer role on the resource group for the project



For more information about access and permissions, see [Assigning users access to projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project).





 Adding users to a project 

Project access is controlled by IBM Cloud Identity and Access Management (IAM). You add users to a project by granting the Reader role or higher on the project instance. For more information on assigning access to projects, see [Assigning users access to projects](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project).





 Adding deployable architecture 

Deployable architectures that you add to a project are represented as configurations in the project UI. After you add a deployable architecture to a project, you can edit your configuration before you deploy it.
[IAM access control in an account](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/tp-in-ag-access-diagram.svg)

Figure 1. How IAM access works in an account by using access groups

For classic infrastructure that doesn't support the use of IBM Cloud IAM policies for managing access, you can use the [classic infrastructure permissions](https://cloud.ibm.com/docs/account?topic=account-mngclassicinfra) documentation.



 What features are provided? 

IBM Cloud IAM provides a wide range of features for your identity and access management needs.



 User management 

With unified user management, you can add and delete users in an account for both platform and classic infrastructure services. You can organize a group of users in an access group to make assigning access for more than one user or service ID at a time a quick and easy task.





 Fine-grained access control 

Access for users, service IDs, access groups, and trusted profiles are defined by a policy. Within the policy, the scope of access can be assigned to a set of resources in a resource group, a single resource, or account management services. After the target is set, you can define what actions are allowed by the subject of the policy by selecting access roles. Roles provide a way to tailor the level of access that is granted for the subject of the policy to perform actions on the target of policy, whether it is platform management tasks within the account or accessing a service's UI or completing API calls.

You can also add time-based conditions to a policy that defines when the policy grants access, whether you want to grant temporary access to resources in your account or allow access during recurring time windows. For more information, see [Limiting access with time-based conditions](https://cloud.ibm.com/docs/account?topic=account-iam-time-based).





 Access groups for streamlined access management
To prevent phishing attacks, IBM Cloud App ID validates the request URL against the allowlist of redirect URLs.



1. In the App ID management console, navigate to Manage Authentication.
2. In the Identity providers tab, make sure that you have an Identity Provider selected. If no Identity Provider is selected, the user will not be authenticated but will be issued an access token for anonymous access to the app.
3. In the Authentication settings tab, add redirect URLs for your app in the format https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Note that all letters in the service instance name must specified as lowercase.



If you use the [IBM Cloud App ID logout function](https://cloud.ibm.com/docs/appid?topic=appid-cd-ssocd-sso-log-out), you must append /sign_out to your domain in the format https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out and include this URL in the redirect URLs list. If you want to use a custom logout page, you must set whitelist_domains in the ConfigMap for OAuth2-Proxy. Call the https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out endpoint with the rd query parameter or set the X-Auth-Request-Redirect header with your custom logout page. For more details, see [Sign out](https://oauth2-proxy.github.io/oauth2-proxy/docs/features/endpoints/sign-out).
3. Bind the App ID service instance to your cluster. The command creates a service key for the service instance, or you can include the --key option to use existing service key credentials. Be sure to bind the service instance to the same namespace that your Ingress resources exist in. Note that all letters in the service instance name must specified as lowercase.