vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Working with teams 

You can use teams to add another dimension of control on the data that is available through a monitoring instance in addition to platform and service access controls. A user with the manager service access role for an IBM Cloud Monitoring instance can create, delete, add members, and change the scope of teams in that instance. Once a team is created, an admin can add a user to it through IBM Cloud® Identity and Access Management (IAM).

In the world of microservices, it is becoming harder to track down valuable metrics and ensure that no sensitive data is exposed. By using teams, administrators can apply a fine grain control on resources. Consider the following information when you work with teams:



* You can create 1 or more teams in a monitoring instance.
* You can specify what resources and metrics are visible for users that are granted IAM permissions to work in the team.
* You can enhance the users experience by customizing the initial dashboard that users in a team get when they launch the web UI.



These instructions assume that you have provisioned a monitoring service instance on IBM Cloud.



 Assigning a user to a team 

To add a user to a team, complete the following steps:



1. Check that you have the administrator platform role to work with the monitoring service or with a specific instance.
2. Define a team level IAM policy for the user. For more information, see [Granting permissions to work in a team](https://cloud.ibm.com/docs/monitoring?topic=monitoring-iam_grant_team).



When the policy is defined, the user is added to the list of users that have access to work with resources configured for a team.





 Creating a team 

You must have manager role to create a team in a monitoring instance.

An administrator or a manager of an IBM Cloud Monitoring instance must switch to the Monitor Operations team before he can create teams and manage existing teams.

Complete the following steps to create a team:



1. [Launch the web UI](https://cloud.ibm.com/docs/monitoring?topic=monitoring-launchlaunch).
2. Click the user icon.
Web apps 

When you are developing a web application, you can use the IBM Cloud® App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.



 Understanding the flow 

Web apps often require users to authenticate to access protected content. App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code, exchange step the tokens are always sent by using a secure backchannel between the app and the OIDC server. This process provides an extra layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.

Zoom

![App ID web app request flow](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/web-flow.svg)

Figure 1. App ID web app request flow



1. A user initiates the authorization flow by sending a request to the /authorization endpoint via the App ID SDK or API.
2. If the user is unauthorized, the authentication flow is started with a redirect to App ID.
3. Depending on the user's /authorization request parameters or identity provider configuration, it starts the Login Widget in the user's browser.
4. The user chooses an identity provider to authenticate with and completes the sign-in process.
5. The identity provider redirects to the client app with the authorization code.
6. The App ID SDK exchanges the authorization code for access, identity, and optional refresh tokens from the App ID service.
7. The tokens are saved by the App ID SDK and a redirect to the client application occurs.
8. The user is granted access to the app.
This issue can occur when another user or application installs the smart contract onto the peer and you do not have the peer admin identity in your browser wallet.

 How to fix it 

In order to view the smart contracts installed on a peer, you need to be a peer admin. Ensure that the peer admin identity exists in your browser wallet. If it does not, you need to import it into your console wallet.





 My nodes, channels, smart contracts, and identities have disappeared from the console. How can I get them back? 

 What’s happening 

Nodes, identities, channels, or smart contracts (or some combination of these) that I successfully deployed into the console are no longer available.

 Why it’s happening 

One of the features of IBM Blockchain Platform is that you are now responsible for securing and managing your certificates. Therefore, they are only persisted in the browser local storage to allow you to manage the component. If you are using a private browser window and then switch to another browser or non-private browser window, the identities that you created will be gone from your wallet in the new browser session. Therefore, it is required that you export the identities from the wallet in your private browser session to your file system. You can then import them into your non-private browser session if they are needed. Otherwise, there is no way to recover them.

 How to fix it 



* Whenever you create a new organization MSP definition, you generate keys for an identity that is allowed to administer the organization. Therefore, during that process you must click the Generate and then Export buttons to store the generated identity in your wallet and then save it to your file system as a JSON file.
* To resolve this problem in your browser, you need to import those identities and associate them with the corresponding node:



* In the browser where you are experiencing the problem, click the Wallet tab followed by Add identity to import the JSON file into your wallet.
* Click Upload JSON and browse to the JSON file you exported using the Add files button.
* Click Submit.
* Now open the peer or ordering service node that this identity was originally associated to, and click on the Settings icon.
* Click the Associate identity button.
"organizational_unit_identifier": "client"
},
"enable": true,
"orderer_ou_identifier": {
"certificate": "LS0tLS1CRUd...LS0tLS0K",
"organizational_unit_identifier": "orderer"
},
"peer_ou_identifier": {
"certificate": "LS0tLS1CRUd...LS0tLS0K",
"organizational_unit_identifier": "peer"
}
},
"host_url": "https://ibpconsole-console.0defdaa0c51eab4bf04a1-0000.us-south.containers.appdomain.cloud:443",
}
Show more





 Step 3: Import MSP into the console 

You have gathered your certificates and built your MSP. Before you can deploy a peer or ordering node, you need to import the MSP JSON file into your IBM Blockchain Platform console.



1. Navigate to the Organizations tab and click Import MSP.
2. Browse to the MSP JSON file and click Add file.
3. Click Import MSP.







 Step 4: Create and import the organization admin identity to the wallet 

To be able to act as an administrator for an organization, import the identity that is listed in the MSP JSON "admins" section into your console wallet, including both the public and private key. When you subsequently deploy a peer or ordering node, you can designate this identity to be the node admin.



1. 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.
For more information, see [Enabling authentication from an external identity provider](https://cloud.ibm.com/docs/account?topic=account-idp-integration).

Both federation options require that the user is a member of the account, or has access to the account by a trusted profile to be able to complete operations. If trusted profiles are not configured, the account owner or administrator must invite individual IBMids into the IBM Cloud account. Only if the invited IBMid accepts the invitation is the user added the account as an active user. In the case of App ID, the user is automatically onboarded to IBM Cloud without a need to invite each user to the account. In both types of federation, the users are active IBM Cloud account users that can access the platform, including IAM-enabled resources and classic infrastructure all depending on their assigned access.

Trusted profiles deal with federated users differently. If the customer federates their corporate IdP, users from that IdP aren't added to an account as what we might consider a typical user. Instead, users' SAML-based IdP attributes are evaluated at login and if they meet all of the conditions for a trusted profile, they are prompted to apply one or more trusted profiles. Trusted profiles grant users the level of access that they need to complete specialized and specific tasks in a limited time-period, for example, 1 - 4 hours. Time-based access allows frequent authentication checks for reduced security risks. These are usually critical tasks that you would want to avoid doing unintentionally in daily work. Users don't need to onboard to IBM Cloud, they're automatically added through the trust relationship. 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.
IBM user IDs 

IBM Cloud® for VMware Solutions maintains a set of users in your account for use by IBM Cloud automation when you run operations such as adding hosts, clusters, or storage to your VMware® instance. Users in your account can also be used for installation and configuration of services by IBM Cloud services automation. Review the following sections for IBM Cloud automation user IDs.

VMware instance operations fail if IBM user IDs are deleted, disabled, or if their passwords are changed.



 vCenter and Platform Services Controller user IDs 

Starting with V2.5, IBM Cloud for VMware Solutions uses the following user IDs to add an identity source, which is embedded by default, into vCenter.



Table 1. vCenter and Platform Services Controller user IDs

 User User ID Method Description 

 IBM root SSH Used for VMware configuration such as setting up VMware High Availability and creating distributed switches. Used post deployment to pair primary and secondary VMware vCenter Server® instances. 
 Customer customerroot SSH Created for customer use only. 
 IBM automation@root_domain <br>(Active Directory™ user) HTTP Used post deployment to add and remove hosts and clusters and to deploy and configure virtual machines (VMs) for services. 
 Customer administrator@vsphere.local HTTP Created for customer use only. 



HTTP is used for vCenter setup, configuration, and VMware operations such as adding hosts, clusters, or storage for vCenter management of resources.





 NSX Manager user IDs 



Table 2. NSX Manager user IDs

 User User ID Description 

 IBM automation@root_domain <br>(Active Directory user) Used post deployment to manage NSX VTEP IP addresses, manage host and cluster configuration when you add and remove hosts and clusters. Also used to manage ESG configuration for services that require public network access for licensing, activation, or usage reporting. 
 Customer admin Created for customer use only. 







 ESXi host user IDs 



Table 3. ESXi host user IDs

 User User ID Description 

 IBM ic4vroot Used post deployment to add more NFS storage, configure routes for that storage, and run all server validation code.
For more information, see this [FAQ](https://cloud.ibm.com/docs/faqsfaq-rmds-4).

The metadata service is disabled by default. You can enable it for new and existing instances in the UI, CLI, or API.
* What information can I get from the metadata service?

The metadata service provides information about your running virtual server instance: instance initialization data, network interface, volume attachment, public SSH key, and placement group information. For a complete list of all information provided, see [Summary of data returned by the metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-metadata-summary).
* What is the instance identity token service?

The instance identity token service lets you generate an instance identity access token that provides a security credential for accessing the metadata. To interact with the instance identity token service, you make a REST API call to the service using a well-known, non-routable IP address. You access the token from within the instance. For more information, see [Instance identity token service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-aboutimd-vpc-access-token).

You can also generate an IAM token from the instance identity access token, and then use the IAM token to access all IAM-enabled services. For more information, see [Generate an IAM token from an instance identity access token](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-service&interface=cliimd-token-exchange).
* Can I use a different DNS name for my ALB?

The auto-assigned DNS name for the application load balancer is not customizable. However, you can add a CNAME (Canonical Name) record that points your preferred DNS name to the auto-assigned load balancer DNS name.
For more information, see this [FAQ](https://cloud.ibm.com/docs?tab=faqsfaq-rmds-4).

The metadata service is disabled by default. You can enable it for new and existing instances in the UI, CLI, or API.
* What information can I get from the metadata service?

The metadata service provides information about your running virtual server instance: instance initialization data, network interface, volume attachment, public SSH key, and placement group information. For a complete list of all information provided, see [Summary of data returned by the metadata service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-metadata-summary).
* What is the instance identity token service?

The instance identity token service lets you generate an instance identity access token that provides a security credential for accessing the metadata. To interact with the instance identity token service, you make a REST API call to the service using a well-known, non-routable IP address. You access the token from within the instance. For more information, see [Instance identity token service](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-aboutimd-vpc-access-token).

You can also generate an IAM token from the instance identity access token, and then use the IAM token to access all IAM-enabled services. For more information, see [Generate an IAM token from an instance identity access token](https://cloud.ibm.com/docs/vpc?topic=vpc-imd-configure-service&interface=cliimd-token-exchange).
* Can I use a different DNS name for my ALB?

The auto-assigned DNS name for the application load balancer is not customizable. However, you can add a CNAME (Canonical Name) record that points your preferred DNS name to the auto-assigned load balancer DNS name.
If your service can be bound to applications in IBM Cloud, it must return API endpoints and credentials to your service consumers. A bindable service must use the bindable operations in the Open Service Broker specification, and implement the following endpoints or paths:

bindings and credentials (PUT)
: Binds your service instance to an application.

bindings and credentials (DEL)
: Unbinds your service instance from an application.





 Required IBM Cloud extension endpoints 

The OSB specification doesn't support a disabled instance state. A disabled state includes a missing payment or other situations that result in an account suspension (but not yet cancellation) and is different from a deleted instance state. In order for IBM Cloud to support customers that might experience a disabled state, IBM Cloud defined the extended API endpoints that allow service instances to be disabled and re-enabled. The following endpoint extensions are required:

enable and disable instances (GET)
: Status - returns the state of your service instance.

enable and disable instances (PUT)
: Enable or disable a service instance.

It's the service provider's responsibility to disable access to the service instance when the disable endpoint starts and to re-enable that access when the enable endpoint is started.







 Broker information provided by the IBM Cloud platform 

Your service broker or brokers receive the following information from the IBM Cloud platform:



 X-Broker-API-Originating-Identity 

The user identity header is provided through an API originating identity header. This request header includes the user's IBM Cloud IAM Identity. The IAM Identity is base64 encoded. IBM Cloud supports a single authentication realm: IBMid. The IBMid realm uses an IBMid Unique ID (IUI) to identify the user's identity in IBM Cloud. This IUI is an opaque string to the service provider.

Example:

X-Broker-API-Originating-Identity: ibmcloud eyJpYW1faWQiOiJJQk1pZC01MEdOUjcxN1lFIn0=
Decoded:
{"iam_id":"IBMid-50GNR717YE"}
Click Add to add your policy configuration to your policy summary.
9. Click Assign.



You also need to have viewer access on the resource group to which your private catalog is assigned. You can assign your private catalog to a resource group when you complete the steps for creating your private catalog. For more information, see [Customizing the IBM Cloud catalog for all account users](https://cloud.ibm.com/docs/account?topic=account-filter-account).

To assign viewer access to your private catalog's resource group, use the following steps:



1. Go to Users and select the user.
2. Select Access > Assign access.
3. Select All Identity and Access enabled services from the list of services.
4. Scope the access to Specific resources based on selected attributes, and select your private catalogs resource group.
5. For Platform access, select the Viewer role.
6. Click Add > Assign.









 Add users to your access groups in the console 

After you set up your access groups, complete the following steps to add users to the groups:



1. Go to Users, and click Invite users.
2. 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. Select one of the three access groups you previously created, and click Add > Invite.
4. Repeat the steps to add users to your other access groups.



Or, you can give users access by adding trusted profiles to your access groups. For more information, see [What makes a good trusted profiles strategy?](https://cloud.ibm.com/docs/account?topic=account-account_setuptrustedprofiles_strategy) and [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).





 Setting up your access groups by using the CLI
In this file, you add the configuration to create a Log Analysis instance and to assign a user an access policy in Identity and Access Management (IAM) by using HashiCorp Configuration Language (HCL). For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).

The following code shows a sample configuration file to provision an instance. To retrieve the ID of the default resource group, the ibm_resource_group data source is used. The region is retrieved from the terraform.tfvars file that you created in step 1. Then, the user user@ibm.com is assigned the Manager role in the IAM access policy for the namespace for a particular region.

data "ibm_resource_group" "group" {
name = var.resource_group_name
}

locals {
instance_name = "${var.name}-${var.location}"
}

// Create a logging instance

resource "ibm_resource_instance" "resource_instance" {
name = local.instance_name
service = var.service_type
plan = var.plan
location = var.location
resource_group_id = data.ibm_resource_group.group.id
tags = ["logging", "public"]
parameters = {
default_receiver= var.default_receiver
}
}

// Create the resource key that is associated with the {{site.data.keyword.la_short}} instance

resource "ibm_resource_key" "resourceKey" {
name = var.key_name
role = "Manager"
resource_instance_id = ibm_resource_instance.instance.id
}

// Add a user policy for using the resource instance

resource "ibm_iam_user_policy" "policy" {
ibm_id = "user@ibm.com"
roles = ["Manager", "Viewer"]

resources {
service = "logdna"
"iss": "https://us-south.appid.cloud.ibm.com/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6050a61",
"aud": [
"968c2306-9aef-4109-bc06-4f5ed6axi24a"
],
"exp": 1551903163,
"tenant": "39a37f57-a227-4bfe-a044-93b6e6050a61",
"iat": 1551899553,
"email": "appid155@mailinator.com",
"name": "appid155@mailinator.com",
"sub": "2b96cc04-eca5-4122-a8de-6e07d14c13a5",
"email_verified": true,
"identities": [
{
"provider": "cloud_directory",
"id": "118c0278-3526-4954-876b-cf70eb88efa2"
}
],
"amr": [
"cloud_directory"
]
}

Identity tokens contain only partial user information. To see all the information that is provided by the identity provider, you can use the [/userinfo endpoint](https://cloud.ibm.com/docs/appid?topic=appid-profilesprofile-predefined-access).





 Refresh tokens 

App ID supports the ability to acquire new access and identity tokens without reauthentication, as defined in [OIDC](https://openid.net/specs/openid-connect-core-1_0.htmlRefreshTokens). A refresh token can be used to renew the access token so a user doesn't have to take any action to sign in, such as providing credentials.
After you have access groups in place, then you can start inviting users to your account and assigning them to the appropriate access group depending on their job responsibilities. For more information, see [Inviting users to an account](https://cloud.ibm.com/docs/account?topic=account-iamuserinv).





 Access groups with dynamic rules 

If you're using an external identity provider, dynamic rules allow you to automatically add federated users to an access group based on SAML assertions. When a user logs in with a federated ID, the data that is provided by your identity provider dynamically maps the user to an access group based on the rules that you set. This can dramatically ease the administration of your account.

For more information see:



1. [Creating dynamic rules for access groups](https://cloud.ibm.com/docs/account?topic=account-rules)
2. [Control access to cloud resources](https://developer.ibm.com/tutorials/use-iam-access-groups-to-effectively-manage-access-to-your-cloud-resources/) - See the section "Background information about access groups and dynamic rules"







 Considerations for enterprises 

If you're using an enterprise, these resources provide additional information:



* [Setting up an enterprise](https://cloud.ibm.com/docs/account?topic=account-enterprise-tutorial)







 Required permissions for services in reference architecture 

The following table provides references to additional information for managing access with IAM for each service in the reference architectures.



Table 1. Managing access for IBM Cloud services in the reference architectures

 Category VPC reference architecture Satellite reference architecture Optional for both 

 Core <br><br> * [VPC infrastructure services](https://cloud.ibm.com/docs/vpc?topic=vpc-resource-authorizations-required-for-api-and-cli-calls)[1]<br><br><br> <br><br> * [Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-iam)<br><br><br>