User provisioning in Oracle Cloud Infrastructure (OCI), whether through manual or automated methods, encompasses the comprehensive management lifecycle of user accounts within the OCI environment. For instance, when a user is provisioned via an Identity Provider (IdP) using the System for Cross-Domain Identity Management (SCIM) protocol or alternatively via Just-In-Time (JIT) provisioning, the user account is configured to possess a full suite of capabilities as outlined below.
This ensures that users are equipped with the necessary access and tools from the onset, facilitating seamless integration and functionality within the OCI framework. Each of these credentials serves different purposes but are all crucial in maintaining the security and integrity of systems and data. They should be securely stored, regularly rotated, and accessed using the principle of least privilege to minimize risks of unauthorized access and data breaches.
Applying the principle of least privilege underscores the understanding that not every user requires access to all capabilities. This approach ensures that individuals are granted only those permissions necessary to perform their specific tasks, thereby enhancing overall security and efficiency. The necessity for specific types of credentials depends largely on the user’s role and the tasks they need to perform within OCI. Here’s a breakdown of who might need which types of credentials and when:
- API Keys
Users: Developers or administrators who need to interact with OCI services programmatically.
Purpose: Used to authenticate API requests made by custom scripts or applications.
- Auth Tokens
Users: Individuals or systems that need to access OCI Object Storage or other OCI services that require these tokens for authentication.
Purpose: Typically used to authenticate non-browser-based interactions with OCI services.
- SMTP Credentials
Users: Users or applications that need to send emails through OCI Email Delivery service.
Purpose: Required for applications that send notifications, alerts, or other communications via email.
- Customer Secret Keys
Users: Users who need to interact with OCI APIs using specific SDKs that require this form of authentication.
Purpose: Used by OCI SDKs for languages like Java, Python, Ruby, or others that require an additional level of security.
- OAuth 2.0 Client Credentials
Users: Applications that need to authenticate against OCI services using the OAuth 2.0 protocol without human interaction.
Purpose: Allows applications to access an OCI service with a token that represents the application’s own identity, not an individual user’s identity.
- Database Passwords
Users: Users who directly access databases hosted on OCI.
Purpose: Essential for database access and management.
The only methods available to update these capabilities are either manually through the UI , CLI or via an API call for each individual user. To streamline this process, we propose a function that could be automatically invoked in response to a user provisioning event. This function would dynamically update user capabilities of your choice, thereby enhancing the automation and efficiency of user management in OCI IAM.
To explain the process, we are going to take an example where the user is created in OCI via Just-In-Time (JIT) provisioning.
As we know Just-In-Time (JIT) provisioning using SAML (Security Assertion Markup Language) is a method that allows for the creation and management of user accounts in Oracle Cloud Infrastructure (OCI) at the time of authentication. This process eliminates the need for pre-provisioning user accounts, simplifying user management, especially for organizations with a large number of users.
When implementing SAML Just-In-Time (JIT) provisioning for Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM), we’ve observed that there is no direct capability to update User Capabilities during the provisioning process. A user being provisioned via SAML JIT will have all capabilities except for a local password.
In the architecture depicted, the function invocation is triggered by a Just-In-Time (JIT) provisioning event for users. This process is facilitated using the Oracle Cloud Infrastructure (OCI) Service Connector Hub, which plays a crucial role in event management and function triggering.
Please note that in this example we are covering the scenario where an event gets triggered for a user provisioning, if the user already exists, we need to address that using a different way, using the same function.
Here’s a breakdown of the steps involved in setting up a system that uses Oracle Cloud Infrastructure (OCI) capabilities to dynamically update user permissions based on Just-In-Time (JIT) provisioning events:
Step 1: Create a Dynamic Group
Purpose: Establish a dynamic group that will be utilized by both the function and the Service Connector Hub to manage user permissions dynamically.
Action: Navigate to the OCI console to create and configure the dynamic group with the appropriate matching rules to include the necessary resources or services.
Step 2: Assign User Administration Role
Purpose: Provide the necessary permissions for the Dynamic Group to manage user capabilities within the domain.This specific role assigned within the IDCS Application implies that the dynamic group JIT_UUC_DG, or resources within it, are granted administrative privileges to manage users within the IDCS environment. This might include creating, modifying, or deleting user accounts. By assigning the User Administrator role to a dynamic group, any OCI resource (like a compute instance or a serverless function) that fits the dynamic group’s criteria can perform these tasks without needing manual credential management.
Action: Assign the User Administration role to the dynamic group to empower it with the necessary authority to update user settings.
Step 3: Create a Policy for the Dynamic Group
Purpose: Authorize the dynamic group to invoke the function that updates user capabilities.
Action: Define and implement a policy in OCI that explicitly allows the dynamic group to execute the function.
Step 4: Develop the Function to Update User Capabilities
Purpose: Create a backend function that programmatically modifies user capabilities based on the JIT event data.
Action: Follow the OCI documentation to develop and deploy the function. Here is a sample code that we used
# A Sample code to edit user capabilities using an OCI Function
import io
import oci
import json
import logging
from fdk import response
from oci.signer import Signer
import requests
def handler(ctx, data: io.BytesIO=None):
logger = logging.getLogger()
logger.setLevel(logging.INFO)
logs = json.loads(data.getvalue())
UserName = str(logs[0]["data"]["additionalDetails"]["actorName"]).lstrip() # From the event we get the userName
domain_id = str(logs[0]["data"]["additionalDetails"]["domainName"]).lstrip() # From the event we get the domainName
idcs_id = str(logs[0]["data"]["additionalDetails"]["actorId"]).lstrip() # From the event we get the User ID
domain_url= 'https://' + domain_id + '.identity.oraclecloud.com' # From the above information, we are construction the domain url
uc_url = domain_url + '/admin/v1/UserCapabilitiesChanger/' + idcs_id # From the above information we collected so far, we are construction the raw request endpoint
valTrue = True # Provide this for the capabilites that the user can have
valFalse = False # Provide this for the capabilites we want to disable for the user
uc_body = {
"canUseConsolePassword":valFalse, # this will false as the user is federated and no need to change this
"canUseApiKeys":valTrue, #make it to true or false as per your requirement
"canUseAuthTokens":valTrue, #make it to true or false as per your requirement
"canUseSmtpCredentials":valFalse, #make it to true or false as per your requirement
"canUseCustomerSecretKeys":valFalse, #make it to true or false as per your requirement
"canUseOAuth2ClientCredentials":valFalse, #make it to true or false as per your requirement
"canUseDbCredentials":valFalse, #make it to true or false as per your requirement
"schemas":["urn:ietf:params:scim:schemas:oracle:idcs:UserCapabilitiesChanger"]
}
logging.getLogger().info(f"Function started - {UserName}")
signer = oci.auth.signers.get_resource_principals_signer()
uc_response = requests.put(uc_url, json=uc_body, auth=signer)
logging.getLogger().info(f"Function ended - {uc_response.text}")
Code Insight: Utilize the actorName, domainName, and actorId from the JIT event within your function to tailor user capabilities. The function will make an OCI raw request to update these settings accordingly.
Step 5: Set Up the Service Connector
Purpose: Automate the triggering of the function in response to JIT provisioning events. As seen in the screenshot above we are capturing events for “UserJit”
Action: Configure a Service Connector in OCI to monitor audit logs for JIT events. Set the function as the target, so it is invoked whenever relevant events are detected.
Create the service connector policies as suggested during the process
Step 6: Testing and Verification
Purpose: Ensure the entire workflow functions as expected without manual intervention.
Action:
- Provision a JIT User: Trigger the JIT provisioning process and monitor the creation of a new user.
-
Initial Verification: Check the newly provisioned user’s capabilities to confirm they are set as default.
-
Event-Driven Invocation: Upon detection of the JIT event by the Service Connector, verify that the function is automatically invoked.
-
Final Outcome: Re-examine the user capabilities post-function invocation to ensure they have been updated correctly according to the event data.
As a safety measure periodically monitor the system and check the logs for the function and the service connector to ensure all operations are performed as expected. Regularly review and refine access controls and permissions to maintain security and compliance.
By following these detailed steps, you can effectively automate the process of updating user capabilities in OCI, leveraging dynamic groups, custom functions, and service connectors to create a responsive and efficient user management system.