vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about how CAs are used to establish identity, see [the identity topic](https://hyperledger-fabric.readthedocs.io/en/release-2.2/identity/identity.html) in the Hyperledger Fabric documentation.

When you create a CA by using the IBM Blockchain Platform console, two CAs are created with the same endpoint URL: a root CA and a TLS CA. The root CA provides keys to your nodes and applications. The TLS CA provides certificates that are used to protect the communication within your network. To learn more about TLS on your network, see [Using your TLS CA](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-identitiesibp-console-identities-tlsca).

When you create your nodes, you need to use your root CA to create the following identities that are required to deploy, operate, and interact with your network:



* CA admin: Your CA contains a default CA admin identity. This identity has an enroll ID and secret, which are analogous to a username and password, that you specify during the deployment of your CA. You can use this admin username and password to operate your CA and create new identities. The CA admin of your root CA is also the admin of the TLS CA.
* Peers or orderers: You need to register an identity for each of the peers and orderers that belong to your organization. Your nodes will then use these identities during deployment to generate the keys they need to participate in the network. For security, create a unique enroll ID and secret for each node you deploy.
* Org admins: When you join a consortium that is hosted by an ordering service, you provide the signing certificates of identities that will become the administrators for your organization. You can use these identities to create or edit channels.
* Peer or orderer admins: IBM Blockchain Platform nodes are deployed with the signing certificates of component administrators identities inside of them. These certificates allow the admins to operate the component from a remote client or by using the console.
* Applications: Your applications need to sign their transactions before submitting them to be validated by the network.
After you create the trusted profile, it auto-generates a service ID. The service ID name begins with iam-Profile, ends with platform-project-access, and includes the ID of the trusted profile in between. If the service ID is ever deleted, it's re-created the next time that the trusted profile is used.





 Coordinating with the administrator on the IBM Cloud Projects service 

The project user who edits the architecture configuration needs identifying information for the trusted profile that you created to complete the authorization. Users need the Operator role or higher on the IBM Cloud Projects service to edit a configuration.

To retrieve the trusted profile ID value, complete the following steps.



 Finding the trusted profile ID 



1. In the IBM Cloud console, click Manage > Access (IAM), and select Trusted profiles.
2. Select the profile that you created for the deployable architecture authorization.
3. Click Details.
4. Copy the Profile ID that begins with Profile.
5. Give this ID to the relevant project user.
In other words, you should never use the same MSP ID to represent different organizations on a network.



* The Root Certificate Authority details tab is where the CA for your organization is specified. This is the CA that you use to register all of the identities associated for your organization. Before creating an MSP, you must register the admin of the MSP. If you use intermediate CAs, this is the CA that you used to create those CAs. Select your CA from the list of CAs managed by using your console. If you created a CA using the console, selecting a CA will also display the root TLS certificate of your TLS CA, which was deployed alongside your CA.
* You can also use the Admin certificates tab to generate the identity of your organization admin. If you already have an admin identity you want to make your organization admin, click Existing identity and select the identity from the drop-down list. If you want to use the panel to generate a new admin identity, you need to register your organization admin with your CA. You then need to complete the following steps in order to use these identities to operate your network:



1. Enter the Enroll ID and Enroll secret of an admin identity that is registered with your CA. After you enter the enroll ID and enroll secret, choose a Display name. This name is used to represent the identity in the console.
2. Click Generate. This generates a certificate and private key and automatically add the keys to your Wallet. You can then find your admin identity in your Wallet by using the name that you selected on this panel. These keys are only stored in your browser local storage. Therefore, if you change browsers, they will not be in your Wallet. This is why you should click Export to export this identity to your local file system. If you switch browsers, you will need to import the identity from your file system into the Wallet of your new browser.
3. Then, click Export to download the key pair to your file system and secure them.



* The Administrators certificate section of the side panel contains the signing certificates keys of your admins. The certificate that you generated by clicking Generate in the section above can be found in the first row of the field.
* Individual user: Enter the email address of the user.
* Access group: Enter the name of the access group of users. You can create an access group with the ibmcloud iam access-group-create command. To list available access groups, run ibmcloud iam access-groups. To add a user to an access group, run ibmcloud iam access-group-user-add <access_group_name> <user_email>.



Resource group
: ClI option: --resource-group-name
: You can grant a policy for a resource group. If you don't specify a resource group or a specific cluster ID, the policy applies to all clusters for all resource groups. To list available resource groups, run ibmcloud resource groups.

Cluster
: ClI option: --service-instance
: You can limit the policy to a single cluster. To list your cluster IDs, run ibmcloud oc cluster ls. Note that if you assign a user the Administrator platform access role for only one cluster, you must also assign the user the Viewer platform access role for all clusters in the region within the resource group.

Region
: ClI option: --region
: You can scope the policy to apply to clusters within a particular region. If you don't specify a region or specific cluster ID, the policy applies to all clusters for all regions. To list available regions, review the [previous region](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-mz) column in the Red Hat OpenShift on IBM Cloud locations table.

Role
: ClI option: --role
: Choose the [platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-iam-platform-access-roles) that you want to assign. Possible values are: Administrator, Operator, Editor, or Viewer.



1. Assign the platform access for the user.



* Assign an individual user the Viewer platform access role to one cluster in the default resource group and US East region:
Creating an IAM access group and granting the role to connect to the VPN server 

FOR USER ID AND PASSCODE AUTHENTICATION ONLY

To create an IAM access group and grant the user role to connect to the VPN server, follow these steps:



1.  From the IBM Cloud console, navigate to the [Access groups](https://cloud.ibm.com/iam/groups) page (Manage > Access (IAM) > Access groups) and click Create.
2.  Type a name for your access group and optional description, then click Create.
3.  Click the Access tab, then click Assign access.
4.  From the drop-down menu, select VPC Infrastructure Services. Then, click Next.
5.  For Resources, select All resources, then click Next.
6.  For Roles and actions, select Users of the VPN server need this role to connect to the VPN server, then click Review.
7.  Review the Create policy summary and click Add.
8.  In the Access summary side panel, click Assign.
9.  Add users to your group.



*  For existing users:



*  Click the Users tab, then click Add users.
*  Select the checkboxes next to each user that requires VPN Client for VPC access, then click Add to group.



*  For new users:



*  Click Manage > Access (IAM), then click Invite users in the upper right.
*  Enter the email address of each user that needs to be invited in the "Enter email address" box. Separate emails by commas, spaces, or line breaks. You can enter up to 100 email addresses.
*  In the group table, click the Add link next to the IAM group that you just created, then click Invite.

Each user receives an email asking them to join an account in IBM Cloud.







For more information, see [Setting up access groups](https://cloud.ibm.com/docs/account?topic=account-groups). For IAM required permissions and the minimum IAM role to perform a task, see [Client-to-site VPN server tasks](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-callsvpn-server-authorizations-required-for-api-and-cli-calls).
Configure user groups 

User Groups allow you to define groups of database-level users and permitted IP addresses, based on the desired role and permission level. User groups are mapped to permissions to create an RBAC policy. User groups are also shared across all applications on your Data Security Broker Manager. If a group's membership is modified, the change is persisted in every policy and application where the group is selected.

Note:



* The Users list can be changed at any time. You are simply changing the membership of a given User Group. There is no impact on the rest of the RBAC configuration, other user groups, or policies.
* Allowed Subnet(s) can be changed at any time. You are changing the allowed subnets for a given User Group. There is no impact on the rest of the RBAC configuration, other user groups, or policies.



To configure RBAC user groups, perform the following:



1. In the Data Protection Policies section, expand RBAC and select User Groups. Click Create User Groups.
2. In the User Groups panel, enter a User Group Name of 30 characters or less, and a unique Description of 100 characters or less.
3. Optional: Select the Global checkbox to create a group where individual Users are ignored.



Anyone connecting to the Shield has membership to this Global group, provided their IP address is within the Allowed Subnets range. If you select Global, proceed with step 5.



1. Enter usernames as a CSV-formatted list in the Users text box.



This is the list of client IDs which Data Security Broker Shield will consider when the User Determination is set to either SESSION or SQL_COMMENT_RAW.



1. Optional: Enter a range of permitted IP addresses as Allowed Subnets. When subnets are configured, a user's membership depends on the following conditions:



a. User is specified in the Users box (User Determination is either SESSION or SQL_COMMENT_RAW) or User is specified by the JWT (User Determination is SQL_COMMENT_JWT) and User has an IP address in the permitted range.

Multiple IP address ranges can be specified for one group, separated by commas.
"id": "8480e26f-3add-4fff-bca7-8cf908894b7c",
"name": "credentials-key",
"type": "application/vnd.ibm.kms.key+json",
"algorithmType": "AES",
"createdBy": "user id ...<redacted>...",
"creationDate": "2020-08-18T16:13:08Z",
"lastUpdateDate": "2020-08-18T16:13:08Z",
"extractable": true,
"payload": "ewoJImhvc3QiOiAibG9jYWxob3N0IiwKCSJkYXRhYmFzZSI6ICJkZXYtYmFja3VwIiwKCSJ1c2VybmFtZSI6ICJteS11c2VybmFtZSIsCgkicGFzc3dvcmQiOiAibXktcGFzc3dvcmQiCn0=",
"state": 1,
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:key:8480e26f-3add-4fff-bca7-8cf908894b7c",
"deleted": false,
"dualAuthDelete": {
"enabled": false
}
}

 decode the payload to get the original string (credentials)
$ echo $PAYLOAD | base64 -d

{
"host": "localhost",
"database": "dev-backup",
"username": "my-username",
"password": "my-password"
}





 Example 7 

Create a root key with an alias, then use that alias to identify the key to show the key details.

 create a root key with an alias
$ ibmcloud kp key create root-key-with-alias -a example-alias --output json

{
[Learn more](https://cloud.ibm.com/docs/account?topic=account-userroles).





 Step 1. Create an IAM access group 

Do the following to create an access group:



1. From the menu bar, click Manage > Access (IAM), and select Access Groups.
2. Click Create.
3. Enter a name and optional description for your group, and click Create.



You can delete a group by selecting the Remove group option. When you remove a group from the account, you are removing all users and service IDs from the group and all access that is assigned to the group.

To create an access group by using the CLI, you can use the [ibmcloud iam access-group-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_access_group_create) command.

ibmcloud iam access-group-create GROUP_NAME [-d, --description DESCRIPTION]





 Step 2. Add permissions to view Activity Tracker instances in the Observability UI 

After you set up your access group, you can assign a common access policy to the group. You must add permissions to view Activity Tracker instances in the Observability UI.

Any policy that you set for an access group applies to all entities, users, and service IDs within the group.

You can assign the policy by using the UI or through the command line.

When you define the policy, you need to select a platform role. Platform management roles cover a range of actions, including the ability to create and delete instances, manage aliases, bindings, and credentials, and manage access. Valid platform roles are administrator, editor, operator, viewer.



 Add permissions through the CLI
If the user does not have a role that is already granted for the selected resource group, choose a role for the Assign access to a resource group field.

Depending on the role that you select, the user can view the resource group on their dashboard, edit the resource group name, or manage user access to the group.

You can select No access, if you want the user to have access only to the IBM Cloud Activity Tracker service in the resource group.
4. Select IBM Cloud Activity Tracker with LogDNA.
5. Select the platform role Viewer.
6. Select the service role Reader.
7. Click Assign.







 Option 3. Grant permissions in a location 

You can only provision 1 instance per location. Therefore, to grant permissions to view events in a region, complete the following steps:



1. Select Assign access to resources.
2. Select IBM Cloud Activity Tracker with LogDNA.
3. Select the instance in the region that the user must have permission to see events.
4. Select the platform role Viewer.
5. Select the service role Reader.
6. Click Assign.









 Step 3. Add a user to the access group 

Continue to set up your group by adding users or service IDs.



 Add a user to the access group 

Complete the following steps to add a user:



1. From the menu bar, click Manage > Access (IAM), and select Access Groups.
2. Select the name of the group that you want to assign access to.
3. Click Add users on the Users tab.
4. Select the users that you want to add from the list, and click Add to group.







 Add a service ID to the access group 

Complete the following steps to add a service ID:



1. From the menu bar, click Manage > Access (IAM), and select Access Groups.
2. Select the name of the group that you want to assign access to.
3. Click the Service IDs tab, and click Add service ID.
4.
* UI
* CLI
* API
* Terraform







 Managing service ID API keys 

Service IDs are created to enable access to your IBM Cloud® services by applications hosted both inside and outside of IBM Cloud. API keys are used by an application to authenticate as a particular service ID and are granted the access that is associated with that specific service ID.

After you create a service ID, you can start creating API keys and assigning service policies. Each policy specifies the level of access that is allowed when the API key is used to authenticate with your services. For more information about creating a service ID and assigning policies, see [Creating and working with service IDs](https://cloud.ibm.com/docs/account?topic=account-serviceids). For more information about the CLI commands that are used to manage service ID API keys, see [Managing IAM access, API keys, service IDs, and access groups](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iam).

Each API key that is associated with a service ID inherits the policy that is assigned to the service ID. For example, if you want one application to view resources within a service, you need to use an API key that is associated with a service ID that has a policy that is assigned with the Viewer role. If you want another application to be able to have full access within a service, then you need to use an API key that is associated with a second service ID that has a policy that is assigned with the Administrator role.

For more information, see [Examples of how to use a service ID](https://cloud.ibm.com/docs/account?topic=account-serviceidsexamples_serviceid).



 Required access for managing service ID API keys 

All users can create service IDs in an account, and they are the administrator for those IDs and can create the associated API key and access policies. However, account owners and users assigned the Administrator role on the IAM Identity service can manage the API keys for all service IDs in an account. Users can also be given access to a single service ID only, if the ID is specified when the administrator assigns the access.
(If the user has not yet authenticated, this cookie does not yet exist.)



const jwtContent = {
sub: anonymousUserID,
user_payload: {
name: 'Anonymous',
custom_user_id: anonymousUserID,
},
};

if (sessionInfo) {
jwtContent.user_payload.name = sessionInfo.userName;
jwtContent.user_payload.custom_user_id = sessionInfo.customUserID;
}



1. Create a function to handle user authentication. In our example, we are using a simple authenticate() function that sets a hardcoded user ID, but in a real application the user ID would probably be retrieved from a database after a secure authentication check. Store the user information in the SESSION_INFO cookie.



function authenticate(request, response) {

const userInfo = {
userName: 'Cade',
customUserID: 'cade-id',
};

response.cookie('SESSION_INFO', JSON.stringify(userInfo), { encode: String });

response.send('Ok');
}



1. When a user logs in, call the authenticate() function to store the user information in the SESSION_INFO cookie. Then call the createJWT() function to regenerate the JWT, using the updated session info to populate the user_payload claim.

In [our example](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-topicid), authentication is simulated with a simple button click. The same button also simulates logging out by deleting the cookie:

async function onClick() {
if (getCookieValue('SESSION_INFO')) {
document.cookie = 'SESSION_INFO=; Max-Age=0';
} else {
await fetch('http://localhost:3001/authenticate');
}
-d "{ "roles": { "ids": [ "<roleIDs>" ] }}"
-H "authorization: Bearer <token>"



To remove a role from a user, make the PUT request again, but remove the role ID.





 Adding user roles to tokens 

By default, roles are not returned in a users token. It is recommended that your runtime decisions are configured based on scopes. But, if you would like to use roles, you can map them to your tokens by using [custom claims mapping](https://cloud.ibm.com/docs/appid?topic=appid-customizing-tokens).

When you authenticate, be sure that you use username : client ID and password : secret for the application and user that you configured controls for.





 Assigning roles to an application 

After you create roles, you can assign them to your applications by using the App ID APIs.

Application roles are only valid in the client credentials flow.



1. Get your application client ID by querying the list of applications. You can also get this value from the Applications tab of the App ID UI.

curl -X GET "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/applications" -H "accept: application/json" -H "authorization: Bearer <token>"

Example:

curl -X GET https://us-south.appid.cloud.ibm.com/management/v4/e19a2778-3262-4986-8875-8khjafsdkhjsdafkjh/applications
-H "accept: application/json"
-H "authorization: Bearer eyJraWQiOiIyMDE3MTEyOSIsImFsZ...."
2. Get the role ID.

curl -X GET "https://<region>.appid.cloud.ibm.com/management/v4/<tenantID>/roles" -H "accept: application/json" -H "authorization: Bearer <token>"
3.
4. Enter the URL of the ServiceNow instance.
5. Enter the Username to be used for connecting to the ServiceNow instance.
6. Enter the Password to be used for authenticating the Username mentioned earlier to authenticate in the ServiceNow instance.
7. Enter the Client ID needed to retrieve the OAuth access token.

Client ID and Client secret are required for accessing your ServiceNow instance. For creating a Client ID and Client secret, check the service now documentation on how to [create an OAuth API endpoint for external clients](https://docs.servicenow.com/csh?context=CSHelp:OAuthSetup).
8. Enter the Client secret required for authenticating the Client ID provided earlier.
9. Enter the approval Group Name defined in ServiceNow. The approval Group Name will contain set of people who are authorized to approve the Change Requests created in the ServiceNow workflow.
10. Set the Change request expiration time (in hours). Minimum 1 to maximum 999 hours.
11. Set the Enabled toggle switch to ON to enable the workflow for selected environment.
12. Click Create to create and apply the workflow.



When you create a workflow in an environment, toggling the feature flags to On state or OFF state in that environment will initiate a change request and need to go through the workflow approval process.

If you have already enabled some feature flags before applying the workflow approval process, those feature flags will function as usual but further toggling will go through an approval process.

If you disable an existing feature flag and apply the workflow, and then enable the feature flag, its status changes to Workflow initiated and a change request workflow will be initiated.



 How to add a mandatory tag to the ServiceNow workflow change request? 

Follow these steps to add a mandatory tag to the change request for the ServiceNow workflow integration:



1. Login to your ServiceNow instance as an administrator.
2. Open an existing Change Request.

Zoom

!