vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IBM Cloud login sequences 

Review the following login sequence flows to understand the details about how federated, non-federated, and users added through IBM Cloud App ID with a SAML provider connected to IBM Cloud® Identity and Access Management (IAM) log in to IBM Cloud.



 Login sequence for non-federated users with an IBMid 

The standard login sequence for users in IBM Cloud that are not federated works according to the following sequence:

Zoom

![Login process for non-federated users with an IBMid](https://cloud.ibm.com/docs-content/v1/content/4d8c6eec891cff72b666dc24bd3211810c77fb42/account/images/login-nonfed-id.svg)

Figure 1. Login process for non-federated users with an IBMid



1. The user starts by visiting the URL [https://cloud.ibm.com](https://cloud.ibm.com) with a browser. The IBM Cloud console sends back a login page to the browser.
2. On the login page, the user enters their username, clicks Continue, then enters their password and sends this information to the console by clicking Log in.
3. The username and password combination is forwarded by the console to the IAM component of IBM Cloud.
4. IAM uses the IBMid system to validate if the username and password combination is correct.
5. After successful validation, IAM responds to the console with a success response and provides a URL that the console should send to the user's browser, so that the user can finish the login sequence.
6. The browser consumes the redirect instruction and navigates to IAM to allow IBM Cloud to finish the login sequence. This browser redirect is necessary to set necessary single-sign-on cookies on the user's browser that prevents the user from entering the login credentials again.
7. IAM then finishes its authentication flow with the console by sending an OAuth2 compliant redirect with an authorization code to the browser.
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 

Quickly and easily assign access for a group of users, service IDs, or trusted profiles that are organized in an access group by assigning access to the group, and then add or remove identities as needed to grant or deny access to account resources. Access groups enable you to manage a minimal number of policies in the account. For more information, see [Setting up access groups](https://cloud.ibm.com/docs/account?topic=account-groups).





 Trusted profiles for eliminating the need to manage credentials 

Automatically grant federated users access to your account with conditions based on SAML attributes from your corporate directory. Trusted profiles can also be used to set up fine-grained authorization for applications that are running in compute resources. This way, you aren't required to create service IDs or API keys for the compute resources. Assign access to the profile by adding it to an access group or by assigning individual policies, and then add or remove conditions as needed to grant or deny access to account resources. By using trusted profiles, you can centrally manage the access lifecycle to multiple IBM Cloud assets. For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).



 Federated users 

Your users might already have identities outside of IBM Cloud in your corporate directory. If your users need to work with IBM Cloud resources or work with applications that access those resources, then those users also need IBM Cloud credentials. You can use a trusted profile to specify permissions for users whose identity is federated from your organization or an external IdP.
For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).



 Federated users 

Your users might already have identities outside of IBM Cloud in your corporate directory. If your users need to work with IBM Cloud resources or work with applications that access those resources, then those users also need IBM Cloud credentials. You can use a trusted profile to specify permissions for users whose identity is federated from your organization or an external IdP. By using your IdP, you can provide a way for users in your company to use single sign-on (SSO). To connect your federated users with IBM Cloud resources, see [Federating users to IBM Cloud](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-iamoverviewfederation-iam).



* Video transcript

We are excited to introduce the latest and greatest identity type: IBM Cloud trusted profiles. You expect the most reliable and efficient way to manage access to your account, so let’s learn about how you can use trusted profiles.

Previously, organizing identities and assigning access was limited to access groups, where each user is added to the account manually.

As an account owner, you can save time and automatically grant federated users access to your accounts by leveraging the attributes that already exist in your corporate directory.

Simply add conditions based on SAML attributes to define which federated users can apply a profile. This way, changes in your directory immediately affect access to resources.

As a federated user, you might have the option to apply one of many trusted profiles. After you log in, you can apply a profile, or continue to the console.

Imagine a scenario where you want to complete developer-related tasks, like working with the service instances from your application components. You can select the Developer profile when logging in to ensure that you have the access you need.

Similarly, if you want to complete an administrator-related task, you can select the Admin profile that has privileged permissions. This way, you reduce the risk of taking privileged actions by mistake.

You also have the option to log in to the account without applying a profile by continuing to the console.
The email address that is used to register becomes the account owner, but you can change this if required later on by following the steps in [Transferring ownership of your account](https://cloud.ibm.com/docs/account?topic=account-transfer&interface=ui).<br><br>When setting up an account for your company or organization, it is best to use a functional ID, some teams call them service accounts, associated with your company. Keep in mind that you will need to monitor for automated emails sent to this email address for warnings about service usage, services being deprecated, new services available, and more.<br><br>When you log in to the account for the first time, you are required to provide a credit card or subscription code to complete your account set up. Later, you can add users by inviting them to the account or by federating to your own corporate directory.<br><br>Users that are added to your account are not required to create their own account.<br><br>For more account-related FAQs, visit [FAQ library for managing your account, resources, and access](https://cloud.ibm.com/docs?tab=faqs&tags=account). 
 <br><br> * Set up SAML federation<br><br><br> By default, when you create an account you use an IBMid for user identity. IBMid is the ID as a Service (IDaaS) from IBM® used to access IBM web-based services, including IBM Cloud resources. The IBMid is based on your company's email address and a password that is managed by IBMid. IBMid allows you to federate to your own corporate directory or a third-party Identity Provider (IdP) service that you might already be using such as Okta.<br><br>Federating to your own directory simplifies the process of adding users to your account as they will not require an IBMid with a separate password.
In the IBM Cloud console, click Manage > Access (IAM), and select Users or Service IDs, depending on which identity you want to assign access.
2. Click on the user or service ID that you want to assign access, then click Access > Assign access.
3. Select Resource group only.
4. Select Add a condition.
5. Select the Resource group attribute type and enter a resource group.
6. Click Next.
7. Select the access roles for viewing or managing the resource group. Then, click Review.
8. Click Add to add your policy configuration to your policy summary.
9. Click Assign.



You can repeat this type of policy as needed for each available resource group in the account to assign access to manage all resource groups in the account.





 Assigning access to resources by using the CLI 



1. Log in to IBM Cloud® CLI. If you have multiple accounts, you are prompted to select which account to use. If you do not specify a region with the -r flag, you must also select a region.

ibmcloud login

If your credentials are rejected, you might be using a federated ID. To log in with a federated ID, use the --sso flag. See [Logging in with a federated ID](https://cloud.ibm.com/docs/account?topic=account-federated_id) for more details.

If it's your first time using the IBM Cloud CLI, check out the [getting started tutorial](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).
2. Create an access policy and assign it to a user or a service ID by using the command [ibmcloud iam user-policy-create](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_iamibmcloud_iam_user_policy_create).



* This example assigns access to an individual resource in the account with the Administrator role for all instances of sample-service service:
The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).





 Creating Users and Getting Connection Strings from the API 

The Foundation Endpoint that is shown on the Overview panel of your service provides the base URL to access this deployment through the API. To create and manage users, use the base URL with the /users endpoint.

curl -X POST 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users' -H "Authorization: Bearer $APIKEY" -H "Content-Type: application/json" -d '{"username":"jane_smith", "password":"newsupersecurepassword"}'

To retrieve user's connection strings, use the base URL with the /users/{userid}/connections endpoint. You must specify in the path which user and which type of endpoint (public or private) should be used in the returned connection strings. The user and endpoint type is not enforced. You can use any user on your deployment with either endpoint (if both exist on your deployment).

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/users/{userid}/connections/{endpoint_type}'

More information is available in the [API Reference](https://cloud.ibm.com/apidocs/cloud-databases-api).





 Adding users in Service Credentials 

Creating a new user from the CLI or API doesn't automatically populate that user's connection strings into Service Credentials. If you want to add them there, you can create a new credential with the existing user information.

Enter the username and password in the JSON field Add Inline Configuration Parameters, or specify a file where the JSON information is stored. For example, {"existing_credentials":{"username":"Robert","password":"supersecure"}}.
For more information, see [Creating trusted profiles](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile).



 Federated users 

Your users might already have identities outside of IBM Cloud in your corporate directory. If your users need to work with IBM Cloud resources or work with applications that access those resources, then those users also need IBM Cloud credentials. You can use a trusted profile to specify permissions for users whose identity is federated from your organization or an external IdP. By using your IdP, you can provide a way for users in your company to use single sign-on (SSO). To connect your federated users with IBM Cloud resources, see [Federating users to IBM Cloud](https://cloud.ibm.com/docs/services/account?topic=account-iamoverviewfederation-iam).



* Video transcript

We are excited to introduce the latest and greatest identity type: IBM Cloud trusted profiles. You expect the most reliable and efficient way to manage access to your account, so let’s learn about how you can use trusted profiles.

Previously, organizing identities and assigning access was limited to access groups, where each user is added to the account manually.

As an account owner, you can save time and automatically grant federated users access to your accounts by leveraging the attributes that already exist in your corporate directory.

Simply add conditions based on SAML attributes to define which federated users can apply a profile. This way, changes in your directory immediately affect access to resources.

As a federated user, you might have the option to apply one of many trusted profiles. After you log in, you can apply a profile, or continue to the console.

Imagine a scenario where you want to complete developer-related tasks, like working with the service instances from your application components. You can select the Developer profile when logging in to ensure that you have the access you need.

Similarly, if you want to complete an administrator-related task, you can select the Admin profile that has privileged permissions. This way, you reduce the risk of taking privileged actions by mistake.

You also have the option to log in to the account without applying a profile by continuing to the console.
],
"roles":[
{
"role_id": "crn:v1:bluemix:public:iam::::role:Administrator"
}
],
"resources":[
{
"attributes":
{
"name": "accountId",
"value": "$ACCOUNT_ID"
},
{
"name": "serviceName",
"value": "iam-identity"
}
]
}
]
}'

Show more

SubjectAttribute subjectAttribute = new SubjectAttribute.Builder()
.name("iam_id")
.value(EXAMPLE_USER_ID)
.build();
PolicySubject policySubjects = new PolicySubject.Builder()
.addAttributes(subjectAttribute)
.build();
PolicyRole policyRoles = new PolicyRole.Builder()
.roleId("crn:v1:bluemix:public:iam::::role:Administrator")
.build();
ResourceAttribute accountIdResourceAttribute = new ResourceAttribute.Builder()
.name("accountId")
.value(exampleAccountId)
.operator("stringEquals")
.build();
ResourceAttribute serviceNameResourceAttribute = new ResourceAttribute.Builder()
.name("serviceType")
.value("iam-identity")
.operator("stringEquals")
.build();
PolicyResource policyResources = new PolicyResource.Builder()
.addAttributes(accountIdResourceAttribute)
.addAttributes(serviceNameResourceAttribute)
.build();
[Actions icon](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/includes/icons/action-menu-icon.svg) > Add tags.
3. Type project:analysis and press Enter.







 Step 3: Create an access group 

You'll define the level of access that users have to your Object Storage based on the tags that you previously created. See the following examples for each access level:



* With reader role, users can list and download objects in buckets.
* With writer role, users can create and delete buckets.
* With manager role, users can control all aspects of data storage, like adding a retention policy and bucket firewall.



First, create an access group to streamline the task of assigning access to multiple users:



1. Click Manage > Access (IAM) in the IBM Cloud console, and select Access groups.
2. Click Create.
3. Enter a unique name to identify your access group, an optional description, and click Create.







 Step 4: Assign a policy 

Next, assign a policy to the group:



1. Click Access > Assign access.
2. Select All Identity and Access enabled services as the service.
3. Scope the access to Specific resources > Access management tags to grant access based on the attached access management tag.
4. Type project:analysis or select it from the list of options.
5. Select the resource group access.
6. Select all roles that apply. To view a list of all actions that are mapped to a specific role, click the numbers listed next to each role.
7. Click Review.
8. Click Add to add your policy configuration to your policy summary.
9. Click Assign.







 Step 5: Add users to your access group 

Then, add users to your access group:



1. Click Users > Add users.
2.
To create the first policy, select All Identity and Access enabled services and click Next.



1. Select All resources and click Next.
2. For the resource group access, select the Administrator role and click Next.
3. Select the Manager service role and the Administrator platform role.
4. Click Add.



2. For the second policy, select All Account Management services and click Next.



1. Select the Administrator role.
2. Click Add.



3. Click Create.







 Granting specific access 

Grant the trusted profile the minimum required access role for the configuration that you're deploying. Choose this option if you have one or only a few deployable architectures with the same access requirements that you plan to deploy to the same target account.

View the catalog page for specific access roles that are required for a given deployable architecture.



1. In the IBM Cloud console, click Catalog.
2. Search for and select the deployable architecture that you're deploying.
3. Click Deploy with IBM Cloud Schematics to view the required access roles.

You're not deploying yet. This is a quick way to view the required access roles.
4. Continue by assigning the trusted profile the required access roles that you viewed in the previous step.

For more information about assigning access, see [Creating the service ID](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-tp-projectcreate-projects-serviceid).
5. Click Create.









 Creating the service ID 

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.
You can [update trusted profiles](https://cloud.ibm.com/docs/account?topic=account-trusted-profile-update) at any time to add trust relationships with compute resources.

You can assign administrator access to everything in an account by creating a trusted profile and assigning two policies to it. To create the first policy, select All Identity and Access enabled services with the Administrator platform role and Manager service role. For the second policy, select All Account Management services with the Administrator role assigned. Users in this access group have administrator access on the [IAM Access Groups service](https://cloud.ibm.com/docs/account?topic=account-account-services&interface=uiaccess-groups-account-management) and can grant or revoke access to all resources and identities in the account by adding or removing users from the access group. They can also manage all administrator access across the account.



 Sample access policies 

Review the following sample access policies to help you determine how you might want to assign trusted profiles access to resources that are organized in resource groups.



* A policy that grants federated users a platform administrator role on the IBM Cloud Kubernetes Service across the entire account. Federated users are allowed to apply this profile when the federated user's external IdP attributes fulfill the conditions of the trust relationship. For example, if your corporate user directory has a jobrole attribute that identifies administrators by the value admin, then you can create a condition that dynamically adds federated users with that attribute to the trusted profile, along with other conditions. The federated users that are allowed to apply the trusted profile can access all instances of this service and create instances of the service in any resource group that they have at least a viewer role assigned. Trusted profiles with an administrator role for a resource can also grant access to that resource. Conditions can be specified so that only federated users that require the highest privileges can apply this trusted profile. All other federated users can be filtered out based on their SAML attributes.
* A policy that grants compute resources Reader and Writer roles on a resource group. When compute resources authenticate and fulfill the conditions that are specified in the trusted profile, such as location or resource type the trusted profile is automatically applied.
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 Log Analysis service in the resource group.
4. Select IBM Log Analysis.
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 Log Analysis.
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. Select the IDs that you want to add from the list, and click Add to group.