vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IA-2 - Identification and Authentication (organizational Users) 



 Control requirements 

IA-2 - 0
: The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users).





 Implementation guidance 

See the resources that follow to learn more about how to implement this control.



* [Handling and securing secrets](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-shared-secrets)







 IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



* IBMid uniquely identifies and authenticates organizational users or processes that act on behalf of organizational users
* IBM Cloud IAM uniquely identifies and authenticates organizational users or processes that act on behalf of organizational users
* Check whether OpenShift cluster has image pull secrets enabled







 NIST supplemental guidance 

Organizational users include employees or individuals that organizations deem to have equivalent status of employees (e.g., contractors, guest researchers). This control applies to all accesses other than: (i) accesses that are explicitly identified and documented in AC-14; and (ii) accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity. Organizations employ passwords, tokens, or biometrics to authenticate user identities, or in the case multifactor authentication, or some combination thereof. Access to organizational information systems is defined as either local access or network access. Local access is any access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to organizational information systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks (e.g., the Internet).
* UI
* API







 Controlling access 

With IBM Cloud® App ID, you can define which users and applications can access specific features or perform specific actions in your apps. To control access, you can create scopes and group them into a role. Then, assign the role to one or more of your app users and applications.

A scope is a runtime action in your application that you register with App ID to create an access permission. A role is a collection of scopes that assigns varying permissions to different types of app users and applications. For example, if your company employs developers, they might create a role that allows them to read and write to the code. If you employ auditors, you might have a view only role as shown in the following image.

Zoom

![App ID access control](https://cloud.ibm.com/docs-content/v1/content/27ecaa7a29890634603881a8e64789974a29916b/appid/images/access-control.png)

Figure 1. How App ID access control works



1. Register runtime actions that can occur in your application with App ID.
2. Compile scopes into groups to form roles.
3. Control access permissions by assigning roles to your users or applications.
4. Configure your application to verify the scopes that are returned in your users access token at run time (or in your applications token if client credentials flow).



For more information about applications, see [Application identity and authorization](https://cloud.ibm.com/docs/appid?topic=appid-app).



 Before you begin 



* You must have an application.
* Make sure you have an understanding of how each type of role and scope can impact your application. Because you're granting access, you want to be sure that you're granting it to only the people that need it.
* Be aware of the [limits](https://cloud.ibm.com/docs/appid?topic=appid-known-issues-limits) that are in place.
To point to a specific instance to use with the CLI, you will need to find your CRN, then run the [instance-target](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-quantum-computing-cliqiskit-runtime-instance-target) command.

To find your CRN, open the IBM Cloud console [Instances page](https://cloud.ibm.com/quantum/instances) and click your instance. In the page that opens, click the icon to copy your CRN. For example:

crn:v1:bluemix:public:qiskit-runtime:us-east:a/b947c1c5a9378d64aed96696e4d76e8e:a3a7f181-35aa-42c8-94d6-7c8ed6e1a94b::





 ibmcloud login 

Use this command to log in to IBM Cloud.

ibmcloud login -a API_ENDPOINT [--sso] [-u USERNAME] [-p PASSWORD] [--apikey KEY | @KEY_FILE]
[--no-iam] [-c (ACCOUNT_ID | ACCOUNT_OWNER_USER_ID) | --no-account]
[-g (RESOURCE_GROUP_NAME | RESOURCE_GROUP_ID)]



 Command options 

-a API_ENDPOINT
: The API endpoint, such as cloud.ibm.com. Required.

--sso
: Specify this option to [log in with a federated ID](https://cloud.ibm.com/docs/iam?topic=iam-federated_id). Using this option prompts you to authenticate with your single sign-on provider and enter a one-time passcode to log in.

-u USERNAME
: The IBM Cloud user name.

-p PASSWORD
: The user password.

--apikey API_KEY or @API_KEY_FILE_PATH
"origin": "BSS",
"self_manage": false
}

See the sample of the requestData field when the User one-time passcode authentication: property is enabled. The requestData.2FA field is set to true.

"action": "user-management.user-setting.update",
"message": "User management service: update user settings",
"requestData": {
"2FA": true,
"iam_id": "IBMid-xxxxx",
"origin": "BSS",
"security_questions_setup": true,
"self_manage": false
}
}

See the sample of the requestData field when the Require MFA security questions at login: property is enabled. The requestData.security_questions_setup field is set to true.

"action": "user-management.user-setting.update",
"message": "User management service: update user settings",
"requestData": {
"2FA": true,
"iam_id": "IBMid-xxxxxx",
"origin": "BSS",
"security_questions_setup": true,
"self_manage": false
}
}





 requestData fields 

The following table lists requestData fields that you can find in events that are generated when user details are modified from the Users dashboard:



Table 15. User management requestData fields

 Field Type Description 

 2FA Boolean Defines the MFA requirements for users in the account. <br>This field is set to true when MFA is enabled for users. 
 allowed_ip_addresses String List of IP addresses from where a user is allowed to access account resources. 
 iam_id String Defines the IBM ID of the user whose settings are being modified. 
 security_questions_setup Boolean Defines when a user requires security questions to log in to the account. <br>This field is set to true to indicate that questions are required.
Your user ID needs account management permissions to manage Activity Tracker Event Routing configurations in the account. You need the administrator role for the Activity Tracker Event Routing service. You might need to contact the account administrator to get permissions to work with Activity Tracker Event Routing. The account owner can grant another user access to the account for the purposes of managing user access, and managing account resources. [Learn more](https://cloud.ibm.com/docs/account?topic=account-account-services).

Choose one of the following options to grant your user permissions:



* [Using the console to assign access](https://cloud.ibm.com/docs/account?topic=account-account-servicesconsole-acct-mgmt)
* [Using the CLI to assign access](https://cloud.ibm.com/docs/account?topic=account-account-servicesusing-the-cli-to-assign-access)
* [Using the API to assign access](https://cloud.ibm.com/docs/account?topic=account-account-servicesapi-acct-mgmt).



Use the serviceNameatracker.





 Step 2: Configure a COS bucket 

Auditing events that are collected in your account can be stored in IBM Cloud Object Storage (COS) buckets.

When you configure Activity Tracker Event Routing, you must define a target per region. The target defines the COS bucket where auditing events in that region are collected.

Before you create a bucket, consider the following information:



* You can create the bucket in any location.
* You can only configure 1 bucket per target.
* You must not share a bucket to collect [location-based auditing events](https://cloud.ibm.com/docs/atracker?topic=atracker-event_typesevent_types_location) from multiple regions.
* If you have regulatory and compliance requirements, check the locations where you can create a bucket. Then, if performance is critical, consider creating the COS bucket in the same region where the auditing events are generated.
Configuration of your App ID instance for IAM integration 

Review the following requirements about how your App ID instance must be configured to work properly as an IAM IdP for your IBM Cloud account.

If you plan to use your App ID instance for IAM IdP integration, then any user can log in to your account who can authenticate with that App ID instance. Therefore, consider following these guidelines when you configure your instance:

Disable the following types of authentication:



* Facebook
* Google
* IBMid
* Anonymous



If you decide to use Cloud Directory as an authentication method, disable the option for users to sign up through the app, and instead add only known users individually to your [Cloud Directory](https://cloud.ibm.com/docs/appid?topic=appid-cloud-directory).



 Setting IAM-specific attributes in App ID tokens 

For IAM to work correctly with your external IdP, you must ensure that the App ID instance provides all of the required attributes. See the following table for the required attributes:



Table 1. Required attributes for App ID tokens

 Attribute App ID ID token claim Source Description 

 identifier (required) ID App ID generated A unique identifier that identifies a user. It can't be changed during the life time of that user. App ID creates this identifier. 
 email (required) email Mapped from SAML assertion "email", which is mandatory for Cloud Directory and SAML configurations. The user's email address. 
 username (recommended) preferred_username if present, otherwise sub Mapped from SAML assertion "preferred_username", "username", "user_name" or "userName" if available. Otherwise, the App ID generated "sub" claim is used When you work with the CLI, APIs, or the IBM Cloud Kubernetes Service, the username displays. A username is often an email address, but can also be a different value. If the username is not provided by App ID, IAM uses the identifier instead.
$ curl --request POST --url 'https://<managementURI>/users --header 'Authorization: Bearer <IAMToken>' --header 'Content-Type: application/json' --data '{"idp": "saml", "idp-identity": "user@ibm.com", "profile": { "attributes": { "role": "admin",
"frequent_flyer_points": 1000 }}}'
4. Verify that registration was successful.



* Check for the user profile that was created.

curl --request GET https://us-south.appid.cloud.ibm.com/management/v4/<tenantID>/users/<userProfileId>/profile --header 'Authorization: Bearer <IAMToken>' --header 'Content-Type: application/json'
* Check for the user ID in the response.

{
"id": "5ce78e09-1356-4ef8-a45d-808b633101db",
"identities": [],
"attributes": {
"role": "manager"
}
}











 Next steps 

Now that you associated a future user with specific attributes, try [accessing or updating attributes](https://cloud.ibm.com/docs/appid?topic=appid-profiles)!
Or, navigate to https://cloud.ibm.com/iam/users.
2. Click your name in the user table.
3. Click the Access policies tab to see your access policies.







 Platform management roles 

The following table details the actions that are mapped to platform management roles. Platform management roles enable users to perform tasks on service resources at the platform level. For example, assign user access for the service, create or delete service IDs, create instances, and bind instances to applications.

For more information about how to assign, edit, review, or delete resource access policies, see [IAM access](https://cloud.ibm.com/docs/account?topic=account-userroles).



Table 1. Platform roles

 Platform role Description 

 Viewer The Viewer role is a required role that allows users to work with namespaces of other accounts. You can also add the appropriate service-specific role for a namespace as described below. 
 Administrator Administrators can create namespaces. The Administrator role is required to perform the service ID and API key lock operations during creation of the service. 







 Service-specific roles 

Service-specific roles determine the scope of an access policy within a specific service. For Cloud Functions, the roles can apply to a users ability to use the service, such as accessing the console or performing API calls.

Permissions build on each other. For example, any operation that the Writer role is able to perform, the Manager role also can. However, the Manager role has additional permissions. To see the general permissions for each role, check out [Service access roles](https://cloud.ibm.com/docs/account?topic=account-userrolesservice_access_roles).

To see which roles are required to perform each operation, check out the following table.



Table 2. Which roles can perform which operations?

 Action Reader Writer Manager 

 functions.namespaces.update <br>Update a namespace. Yes 
 functions.namespaces.delete <br>Delete a namespace. Yes 
 functions.namespaces.read <br>View the available namespaces.
To point to a specific instance to use with the CLI, you will need to find your CRN, then run the [instance-target](https://cloud.ibm.com/docs/cli?topic=cli-quantum-computing-cliqiskit-runtime-instance-target) command.

To find your CRN, open the IBM Cloud console [Instances page](https://cloud.ibm.com/quantum/instances) and click your instance. In the page that opens, click the icon to copy your CRN. For example:

crn:v1:bluemix:public:qiskit-runtime:us-east:a/b947c1c5a9378d64aed96696e4d76e8e:a3a7f181-35aa-42c8-94d6-7c8ed6e1a94b::





 ibmcloud login 

Use this command to log in to IBM Cloud.

ibmcloud login -a API_ENDPOINT [--sso] [-u USERNAME] [-p PASSWORD] [--apikey KEY | @KEY_FILE]
[--no-iam] [-c (ACCOUNT_ID | ACCOUNT_OWNER_USER_ID) | --no-account]
[-g (RESOURCE_GROUP_NAME | RESOURCE_GROUP_ID)]



 Command options 

-a API_ENDPOINT
: The API endpoint, such as cloud.ibm.com. Required.

--sso
: Specify this option to [log in with a federated ID](https://cloud.ibm.com/docs/iam?topic=iam-federated_id). Using this option prompts you to authenticate with your single sign-on provider and enter a one-time passcode to log in.

-u USERNAME
: The IBM Cloud user name.

-p PASSWORD
: The user password.

--apikey API_KEY or @API_KEY_FILE_PATH
: The API key content or the path of an API key file that is indicated by the @ symbol.
To do this in our application, we will set a new promptOption flag when the client receives an option response. When this flag is true, we know that we want to take the next round of input from value.input rather than accepting natural language text input from the user. (Again, we don't have a real user interface, so we will just prompt the user to select a valid option from the list by number.)

// Option example 2: sends back selected option value.

const prompt = require('prompt-sync')();
const AssistantV2 = require('ibm-watson/assistant/v2');
const { IamAuthenticator } = require('ibm-watson/auth');

// Set up Assistant service wrapper.
const service = new AssistantV2({
version: '2019-02-28',
authenticator: new IamAuthenticator({
apikey: '{apikey}', // replace with API key
})
});

const assistantId = '{assistant_id}'; // replace with assistant ID
let sessionId;

// Create session.
service
.createSession({
assistantId,
})
.then(res => {
sessionId = res.result.session_id;
sendMessage({
messageType: 'text',
text: '', // start conversation with empty message
});
})
.catch(err => {
console.log(err); // something went wrong
});

// Send message to assistant.
function sendMessage(messageInput) {
service
.message({
assistantId,
sessionId,
input: messageInput,
})
.then(res => {
processResponse(res.result);
})
.catch(err => {
console.log(err); // something went wrong
});
}
Get a snapshot of the bastion server for backup and recovery.





 Before you begin 



* If Terraform is not installed on your machine, [Install the Terraform CLI and the IBM Cloud Provider plug-in](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-setup_cli). The minimum Terraform version that is required is v0.14. You also need to install any software that your operating system requires for Terraform, for example Homebrew for Macs.
* [Create or retrieve an IBM Cloud API key](https://cloud.ibm.com/docs/account?topic=account-userapikeycreate_user_key). The API key is used to authenticate with the IBM Cloud platform and to determine your permissions for IBM Cloud services.
* If you do not know your resource group ID, go to Manage > Account > Resource Groups and locate the resource group ID.
* [Create or retrieve your SSH key name](https://cloud.ibm.com/docs/ssh-keys?topic=ssh-keys-getting-started-tutorial). The SSH key is used to SSH to the bastion server.
* Collect the general information that you need to specify for the script parameters:



 Component type Parameter values needed 

 User-specific information <br><br> * API key<br> * SSH key or keys<br> * Resource Group<br> * IP address or addresses<br> * Your local machine OS<br> * Prefix to add to the resource names<br><br><br> 
 Supported OS type <br><br> * Linux<br><br><br> 
 Zone The zone where resources are deployed 
 Image to use for region VSIs <br><br> * Bastion Server<br> * App Server<br> * Web Server <br> Images are region-specific.
If the access policy is scoped to a particular location, the policy must be scoped to the location ID, not to the location's name.





 Ask the location owner to update your permissions 

Ask the location owner to update your access policy in IBM Cloud IAM so that access to Satellite locations is no longer scoped to locations. The steps vary depending on how the location owner set up your access policy. The following commands provide examples for updating access group and individual policies from the CLI. For more information, see [Managing access for Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-iam).



1. Log in to IBM Cloud. If you have a federated account, include the --sso option.

ibmcloud login [--sso]
2. List the access policies for the user or access group, and note the Policy ID that grants access to the Satellite location.



* For individual users

ibmcloud iam user-policies <user@email.com>
* For access groups

ibmcloud iam access-group-policies <access_group>

Example output

Policy ID: 11a11111-bb2b-3c33-444d-ee5ee55ee55e
Roles: Viewer
Resources:
Service Name satellite
Resource Type location



3. Update the access policy so that the policy is no longer scoped to locations.



* For individual users

ibmcloud iam user-policy-update <user@email.com> <policy_ID> --roles Viewer --service-name satellite
* For access groups

ibmcloud iam access-group-policy-update <group> <policy_ID> --roles Viewer --service-name satellite

Example output

Policy ID: 11a11111-bb2b-3c33-444d-ee5ee55ee55e
Version: 2-111aaa1111a1a1aa1a1a11aa11a1aa11
Roles: Viewer
Resources:
Service Name satellite
Auditing events for App ID 

You can view, manage, and analyze user-initiated activities that are made in your IBM Cloud® App ID service instance by using the Activity Tracker service.

By integrating Activity Tracker with App ID, you can track two different types of events, administrative and runtime. Administrative events are specific to your instance of the service. Administrative events cover configuration changes such as updating your identity providers or changing the theme of your login widget. Runtime events are those activities that occur at run time by the app user. A password reset request, authentication failures, or a user logout would all fall into the runtime category.

For more information about how the service works, see the [Activity Tracker docs](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started).



 Viewing administrative events 

You can view, manage, and analyze configuration activity that is made in your App ID instance by using the Activity Tracker service.



 Monitoring administrative activity 



1. Log in to your IBM Cloud account.
2. From the catalog, provision an instance of the Activity Tracker service in the same account and region as your App ID instance.
3. From the Observability > Activity Tracker tab, verify the information for the instance that you created.
4. Click View Open Dashboard and make sure you're on the Everything dashboard. Any events that meet the qualifications for your Activity Tracker payment plan are visible. You can filter your results by tags, sources, apps, or levels. You can also search for specific events or jump to a specific timeframe.









 List of administrative events 

Check out the following table for a list of the events that are sent to Activity Tracker.

Some action names were changed as part of an alignment to new guidelines. [Learn more](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-eventaction_field).



Table 1. Actions that you can take that are tracked by Activity Tracker

 Action Description GUI action 

 appid.recent-activity.read View recent activity. Can be found in the Activity Log box on the Overview tab.
Granting access to keys 

You can enable different levels of access to IBM® Key Protect resources in your IBM Cloud account by creating and modifying IBM Cloud IAM access policies.

Account admins should determine an [access policy type](https://cloud.ibm.com/docs/account?topic=account-userrolespolicytypes) for users, service IDs, and

access groupsbased on internal access control requirements. These access controls can be assigned at multiple levels, from instances down to individual keys. For example, if you want to grant user access to Key Protect at the smallest scope available, you can [assign access to a single key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-grant-access-keysgrant-access-key-level) in an instance.



 Granting access to all keys in an instance 

Review [roles and permissions](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-access) to learn how IBM Cloud IAM roles map to Key Protect actions.

To grant access to keys within a Key Protect instance by using the IBM Cloud console:



1. From the menu bar, click Manage > Access (IAM), and select Users to browse the existing users in your account.
2. Select a table row, and click the ⋯ icon to open a list of options for that user.
3. From the options menu, click Assign access.
4. Click Assign access.
5. Choose whether you want to assign access to a group (by clicking Access group) or to an individual (by clicking Access policies). Your access groups can be found by clicking Access groups in the Manage access section of the left navigation.
6. From the list of services, select Key Protect and click Next to open the Resources section.
7. In the Resources section, use the radio buttons to select whether you assign access over all resources or only specific resources. If you select Specific resources you are asked to provide an Attribute type (for example, a Key ring ID, where the string equals the ID).