Role Based Access Control (RBAC)


Introduction

Cripsa Inc offers a comprehensive API suite to enable Role-Based Access Control (RBAC) in your applications, providing a powerful mechanism to manage user access and permissions. RBAC ensures that users are granted appropriate levels of access based on their roles, responsibilities, and required actions. The following key APIs are at the core of Cripsa Inc's RBAC system:


  • CreateProjectWithMFA and CreateProjectWithoutMFA: These APIs allow you to establish projects with or without Multi-Factor Authentication (MFA). Creating projects serves as the foundational step in setting up RBAC for different application components or services. You can choose the suitable MFA option based on your security requirements.
  • CreateUser: This API facilitates the creation of user accounts within the established projects. Users can be assigned specific roles, actions, and attributes during the creation process, which will be crucial for role-based access control.
  • UpdateUserAttributes: This API is instrumental in modifying user attributes like roles, actions, and attributes. With this API, you can dynamically adjust a user's access privileges based on changing requirements or responsibilities.
  • GetUserInformation: This API enables the retrieval of detailed user information, including roles, actions, attributes, and other relevant data. It empowers administrators to review user profiles and access levels for effective RBAC management.
  • GetAccessIdTokenFromCode: This API plays a vital role in managing user sessions and authentication. It allows users to obtain the necessary tokens (Access Token, ID Token, and Refresh Token) required for secure access to your application's resources.
  • DeleteUser: The "Delete User" API is important for RBAC as it enables the removal of user accounts that no longer require access. This is a key component of RBAC maintenance and helps manage access privileges effectively.

By combining these APIs, you can implement a robust RBAC system that controls user access based on defined roles, actions, and attributes. This approach ensures that each user has the appropriate level of access, enhancing security and preventing unauthorized usage. Whether you are securing different service components or adhering to specific compliance requirements, Cripsa Inc's RBAC API suite offers a versatile solution to effectively manage user access and permissions in your applications.


Designing Roles

Role design is a critical aspect of establishing effective access control and permissions within your application or system. A well-defined role not only represents a set of permissions but also provides clarity on the actions a user can perform. Cripsa Inc advocates a role-naming convention that combines the Application or Service Name with a suitable word that succinctly summarizes all the actions or permissions associated with the role.


This convention offers several advantages. First, it provides immediate context by including the application or service name, making it clear which part of the system the role pertains to. Second, by appending a descriptive term that summarizes the permitted actions, the role's purpose becomes apparent without needing to delve into its detailed configuration. This approach aids administrators and developers in understanding the role's intent and scope.


For instance, consider an application named "App01" that requires different levels of access, such as "Update," "Delete," "Read," "Create," and "Administer." By following the recommended convention, you would name the role as "App01AdministrationRole." This name encapsulates both the application name and the summarized actions allowed by the role. This simple yet effective naming strategy enhances clarity, reduces ambiguity, and fosters better management of roles and their associated permissions.


Visually, the concept can be illustrated as follows, considering an organizational setup with two distinct applications, namely "App01" and "App02." In this context, the focus is on devising roles that grant diverse permissions to end users across these applications:


One Login SAML Image-1

Figure 1: Password-MFA Login Screen


Implementing roles in this manner not only improves the organization and communication of permissions within your system but also enhances security by ensuring that each role's purpose is evident. Whether you are implementing Role-Based Access Control (RBAC) or managing user access in a complex environment, adopting a role-naming convention that includes the application or service name along with a concise summary of actions simplifies the management and understanding of role-based access throughout the application's lifecycle.


Designing Action

The Action attribute design in Cripsa Inc follows a strategic convention that efficiently organizes and identifies user actions within an application or service. This approach ensures clarity and precision in defining roles and access permissions. Each action name incorporates the Application or Service Name, followed by a colon (:), and then a list of allowed actions. If multiple actions are applicable, they are separated by commas. This structured format enhances the readability and management of roles, making it easy to associate specific actions with their corresponding services.


For instance, consider an application named "App01" with various actions allowed, such as "Update," "Delete," "Read," "Create," and "Administer." In the Action attribute, these actions would be listed as follows:

action: "App01:Update, App01:Delete, App01:Read, App01:Create, App01:Administer"

Visually, the concept can be illustrated as follows, considering an organizational setup with two distinct applications, namely "App01" and "App02." In this context, the focus is on devising roles and actions that grant diverse permissions to end users across these applications:


One Login SAML Image-1

Figure 2: Example of Action and Role Definition Based on Permission


This systematic approach ensures that each action is explicitly linked to the respective application or service, preventing confusion and errors when defining roles. Additionally, when implementing Role-Based Access Control (RBAC), this convention provides administrators with a clear overview of the actions associated with each role, facilitating efficient assignment of permissions and access levels.


By adhering to this Action attribute design, Cripsa Inc empowers developers and administrators to create a structured and organized framework for managing user access and permissions, contributing to the overall security and effectiveness of the application's access control strategy.


RBAC Development Workflow

Workflow: User Access Management with RBAC Using Cripsa Inc API is as follows:


  • Project Creation for RBAC: - Developer initiates the RBAC process by creating a project through Cripsa Inc's APIs: "CreateProjectWithoutMFA" or "CreateProjectWithMFA".
  • Develop Sign-In UI: - The output obtained from the project creation step is utilized to design and develop the user-friendly Sign-In User Interface (UI) for end users.
  • Role Design: - Design of necessary roles for the Customer's application is carried out based on the guidance provided in the Role Design Section of the document.
  • User Attributes Update: - Users are created and their attributes are updated using the "UpdateUserAttribute" API endpoint. Attributes such as roles, actions, groups, and custom attributes are included in the request parameters.
  • User Sign-In: - End users access the Sign-In UI to log in to the Customer Application/Service.
  • Code Generation: - After successful user authentication, Cripsa Inc generates a unique code that serves as a secure token.
  • Token Retrieval:- The Customer Application uses the generated code to call the "gettokenfromcode" API endpoint, requesting tokens such as Access Token and Refresh Token.
  • Token Delivery: - Cripsa Inc provides the requested tokens (Access Token and Refresh Token) to the Customer Application.
  • User Attributes Retrieval: - The Customer Application queries the "userinfofromtoken" API endpoint to receive a comprehensive JSON-format detail of user attributes.
  • User Attributes Provided: - Cripsa Inc delivers the JSON-format user attribute details, including roles, actions, groups, and custom attributes.
  • Attribute-Based Logic:- The Customer Application's development team extracts pertinent attributes from the user attribute JSON format. They devise logical mechanisms to grant relevant access to users based on their attribute details.
  • Access Authorization:- With the applied logic and attribute-based access control, end users are granted access to the Customer Application/Service with appropriate authorization levels, adhering to the defined roles and permissions.

Visually, the concept can be illustrated as follows:


RBAC

Figure 3: RBAC Workflow detail


This workflow illustrates the sequential steps required to implement a comprehensive user access management system utilizing Role-Based Access Control (RBAC) principles and leveraging Cripsa Inc's API endpoints. It ensures that end users are provided the correct access and authorization based on their defined attributes and roles within the system.


RBAC

Figure 4: Complete Visualization detail of RBAC


Create User

The payload for this API call would be like the following:


RBAC

Note: Here “email”, “password” and “userPoolId” element is only mandatory. Rest all are optional. One can include the following elements (attributes) as well as part of this user creation request.


Attribute Fields Type Description
sub string Subject - Identifier for the End-User at the Issuer.
name string End-User's full name in displayable form including all name parts, possibly including titles and suffixes, ordered according to the End-User's locale and preferences.
given_name string Given name(s) or first name(s) of the End-User. Note that in some cultures, people can have multiple given names; all can be present, with the names being separated by space characters.
family_name string Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.
middle_name string Middle name(s) of the End-User. Note that in some cultures, people can have multiple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used.
nickname string Casual name of the End-User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael.
preferred_username string Shorthand name by which the End-User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7.
Profile string URL of the End-User's profile page. The contents of this Web page SHOULD be about the End-User.
picture string URL of the End-User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-User suitable for displaying when describing the End-User, rather than an arbitrary photo taken by the End-User.
website string URL of the End-User's Web page or blog. This Web page SHOULD contain information published by the End-User or an organization that the End-User is affiliated with.
email string End-User's preferred e-mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-spec syntax. The RP MUST NOT rely upon this value being unique, as discussed in Section 5.7.
email_verified boolean True if the End-User's e-mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this e-mail address was controlled by the End-User at the time the verification was performed. The means by which an e-mail address is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating.
gender string End-User's gender. Values defined by this specification are female and male. Other values MAY be used when neither of the defined values are applicable.
birthdate string End-User's birthday, represented as an ISO 8601:2004 [ISO8601 2004] YYYY-MM-DD format. The year MAY be 0000, indicating that it is omitted. To represent only the year, YYYY format is allowed. Note that depending on the underlying platform's date related function, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates.
zoneinfo string String from zoneinfo [zoneinfo] time zone database representing the End-User's time zone. For example, Europe/Paris or America/Los_Angeles.
locale string End-User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-1 Alpha-2 [ISO639 1] language code in lowercase and an ISO 3166-1 Alpha-2 [ISO3166 1] country code in uppercase, separated by a dash. For example, en-US or fr-CA. As a compatibility note, some implementations have used an underscore as the separator rather than a dash, for example, en_US; Relying Parties MAY choose to accept this locale syntax as well.
phone_number string End-User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-1234;ext=5678.
phone_number_verified boolean True if the End-User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirmative steps to ensure that this phone number was controlled by the End-User at the time the verification was performed. The means by which a phone number is verified is context-specific, and dependent upon the trust framework or contractual agreements within which the parties are operating. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format.
address string End-User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Section 5.1.1.
updated_at number Time the End-User's information was last updated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.

In such case the payload of the createuser API is as follows:


RBAC

Call the URL: https://api.cripsa.com/v2/rbac/createuser


RBAC

Note: Please make sure that in the Header you are sending your own API Key which has been generated while creation of the project.


RBAC

One can find the reference code here:


https://cripsa.com/rbac-create-user


How to verify what Role/Attribute/Group associated with User

In the context of user access management and Role-Based Access Control (RBAC), Cripsa Inc offers two APIs, namely "GetAccessTokensFromCode" and "userInfoFromAccessToken," which enable developers to verify the roles, attributes, and groups associated with end users. These APIs play a crucial role in providing detailed user information and access control within applications or services.


  • GetAccessTokensFromCode API: The "GetAccessTokensFromCode" API facilitates the exchange of a code generated during the user authentication process for access tokens, including an Access Token and a Refresh Token. This exchange is an essential step in securing user access and maintaining session validity. The API performs the following key tasks:
  • a. Validates the provided code from the user authentication process.

    b. Generates an Access Token, which is a short-lived token that grants access to specific resources within the application.

    c. Generates a Refresh Token, which allows the application to request a new Access Token without requiring the user to log in again.

  • userInfoFromAccessToken API: The "userInfoFromAccessToken" API serves as a valuable tool to retrieve comprehensive user attribute information associated with a given Access Token. This information includes roles, attributes, groups, and other relevant details. The API offers the following features:
  • a. Verifies the provided Access Token's validity and authenticity.

    b. Retrieves a JSON-format response containing a wide range of user attributes, such as roles, attributes, groups, and more.

    c. Enables developers to parse and extract specific user details required for access control and user interaction.


Workflow: Verifying User Role, Attribute, and Group:

    Authentication and Code Generation:

  • a. End users authenticate themselves using the application's sign-in process.
  • b. Cripsa Inc generates a code and provides it to the application.

    Token Exchange:

  • c. The application utilizes the "GetAccessTokensFromCode" API to exchange the code for an Access Token and a Refresh Token.

    User Attribute Retrieval:

  • d. To verify user roles, attributes, and groups, the application employs the "userInfoFromAccessToken" API.
  • e. The API requires the Access Token to fetch user information.

    Access Control and Verification:

  • f. The API response contains a JSON format detailing user attributes, including roles, attributes, and groups.
  • g. Developers can parse this JSON response to identify the user's associated roles, attributes, and groups.

    Attribute-Based Logic:

  • h. Based on the user's attributes, the application's logic determines access permissions and privileges.
  • i. Roles, attributes, and groups guide the application in granting appropriate access levels and actions to the user.

By integrating these two APIs into the application's user access management process, developers can effectively verify the roles, attributes, and groups associated with end users. This verification process enhances security, promotes effective access control, and ensures that users are granted appropriate access based on their defined attributes within the system. The following two sections will provide more information on the above mentioned two APIs.


Getting Tokens (Access and Refresh) from Code

The payload for this API call would be like the following:


RBAC

Call the URL: https://api.cripsa.com/v2/rbac/gettokenfromcode


RBAC

Note: Please make sure that in the Header you are sending your own API Key which has been generated while creation of the project.


RBAC

The Response would be as follows:


RBAC

9One can find the reference code here:


https://cripsa.com/rbac-get-token-from-code


Get User Detail from Access Token

In the context of our operational framework, Cripsa Inc offers a valuable resource for our client's access control processes. With Cripsa's provided API endpoints, our client gains the capability to extract vital user information directly from the Access Token. This functionality plays a pivotal role in enhancing our access control decisions and user experience.


As our client's applications navigate the intricacies of access provisioning, they rely on a spectrum of application logic informed by prior interactions. These decisions often hinge on the authenticity and validity of Access Tokens. Cripsa's "userinfofromaccesstoken" API endpoint, integrated seamlessly into our system, presents a streamlined approach to acquire crucial user details from the Access Token.


When an Access Token's validity is questioned, our process involves assessing the AccessToken's signature and expiration status. Upon a positive outcome, the client's application interfaces with the "userinfofromaccesstoken" endpoint. This interaction initiates the retrieval of pertinent user information, empowering our access control systems with the necessary data to make informed choices.


By adopting this approach, our client elevates both security and efficiency in its operations. The seamless integration of Cripsa's API endpoints accelerates the acquisition of user information, fostering accurate and responsive access control decisions. This synergy between token verification and user information extraction reinforces our commitment to a robust, user-centric approach to access management.


To User Information from Access Token, the API end point is as follows:


https://api.cripsa.com/v2/rbac/userinfofromaccesstoken


The payload of verify access token is as follows:


RBAC

Note: Please make sure that in the Header you are sending your own API Key which has been generated while creation of the project.


RBAC

The Postman Output is as follows:


RBAC

Now, the client employs diverse application logic based on the outcomes of the aforementioned call, determining whether to permit or refuse access to end users. The essential fields highlighted in the provided screenshot guide this decision-making process.


As a pivotal aspect of implementing Role-Based Access Control (RBAC) for robust user permission management, custom attributes have been introduced. These attributes encompass roles, actions, attributes, and groups, forming a crucial foundation for configuring RBAC to cater to the specific requirements of your organization's access control strategy.


RBAC
Granular Control with Custom Attributes:

For organizations operating multiple services and necessitating meticulous control over user access, these custom attributes hold significant importance. These attributes enable precise control over access based on factors such as service name, allowed actions, or user-specific attributes like department or destination.


Granular Control with Custom Attributes:

For organizations operating multiple services and necessitating meticulous control over user access, these custom attributes hold significant importance. These attributes enable precise control over access based on factors such as service name, allowed actions, or user-specific attributes like department or destination.


Illustrative Example:

Consider an application or service named "App01" within your operational landscape. You aim to establish a role that encompasses a spectrum of actions, including Update, Delete, Read, Create, and Administer. Additionally, you intend to restrict this role to specific departments, such as "ITAdminDept" and "FinanceAdminDept."


Following a structured convention for attribute values:


- "action": ": "

- "roles": "+"

- "attribute": ""


In our illustrative scenario, the attribute values are formulated as:


- "action": "App01:Update, App01:Delete, App01:Read, App01:Administer"

- "roles": "App01AdministrationRole"

- "attributes": "ITAdminDept, FinanceAdminDept"


It's important to acknowledge that the system provides the flexibility to assign both roles and groups, or opt for assigning either a group or a role in isolation, based on your operational demands. This flexibility empowers you to meticulously calibrate user access privileges, aligning seamlessly with your organization's security and operational requisites.


By comprehending and embracing the potential of custom attributes, your organization can strategically deploy RBAC to ensure that users possess precisely tailored access, contributing to enhanced security and streamlined operational efficiency.


The reference detail one can find in the URL :


https://cripsa.com/rbac-user-info-by-access-token


Update User Role (Profile/Attributes) and Getting User RBAC detail through Access Token

Cripsa Inc is dedicated to enhancing user experience and providing developers with robust tools for efficient identity and access management. As part of our commitment, we offer a powerful API that enables seamless updates to user attributes within your applications. This API empowers developers to dynamically modify user attributes, such as roles, group affiliations, preferences, and more, in a secure and controlled manner.


Through this API, developers can seamlessly integrate attribute updates into their application's workflows, ensuring that user profiles remain up-to-date and relevant. Whether you need to adjust roles to grant specific privileges, update contact information, or reflect changes in group affiliations, the Cripsa Inc API for User Attribute Update simplifies the process.


Developers can send requests to the designated endpoint, providing the necessary user identifier and the updated attribute values. Our API securely handles the update process, ensuring data integrity and authentication. This capability proves invaluable in scenarios where user information needs to be adapted without requiring users to undergo an entire authentication process.


Incorporating the Cripsa Inc User Attribute Update API streamlines application maintenance, enhances user personalization, and ensures that user data remains accurate. By seamlessly integrating attribute updates, developers can create applications that reflect real-time user preferences and attributes, enhancing overall user satisfaction and engagement.


To Update User Attributes, the API end point is as follows:


https://api.cripsa.com/v2/rbac/updateuserattribute


The payload of verify access token is as follows:


RBAC

Note: In the above screen shot the first two attributes (email and userPoolId) are mandatory. Rest all are optional.


As an integral part of implementing Role-Based Access Control (RBAC) to manage user permissions effectively, we have introduced custom attributes that include roles, actions, attributes, and groups. These attributes play a crucial role in configuring RBAC to match your organization's specific needs.


If your organization operates multiple services and requires granular control over user access based on service name, permitted actions, or specific attributes like department or destination, these custom attributes are key. By tailoring the attribute values, you can precisely define the access privileges for different users.


Please see “Illustrative Example” above to design Roles and actions.


Note: Please make sure that in the Header you are sending your own API Key which has been generated while creation of the project.


RBAC

The Postman Output is as follows:


RBAC

Upon the user's subsequent sign-in, the ID Token will encompass all the associated user attributes. To retrieve the user information, utilize the following API:

https://cripsa.com/rbac-user-info-by-access-token

However, prior to accessing this, you need to utilize the provided code to obtain the Access Token, ID Token, and Refresh Token via the API at

https://api.cripsa.com/v2/rbac/gettokenfromcode


RBAC

Now, your application's logic can capture the highlighted elements and grant access to your application based on whether the appropriate Role-Action or Group has been assigned. Additionally, access can also be controlled through the use of "attributes".


The reference of the API detail one can find in the URL :


https://cripsa.com/rbac-update-user-attribute


Delete User

Cripsa Inc offers a comprehensive API that empowers organizations with the capability to efficiently manage user accounts. One of the key functionalities is the "Delete User" API, which allows for seamless removal of user accounts from the system. This API ensures that administrators and developers have a reliable mechanism to handle account deletions when required.


By leveraging the "Delete User" API provided by Cripsa Inc, administrators can easily trigger the removal of user accounts that are no longer needed or have become inactive. This API streamlines the process of account management, helping to maintain a clean and organized user base within applications and services.


It's essential to understand that using the "Delete User" API should be carried out with careful consideration, as this action is irreversible and permanently removes user accounts and associated data. As such, organizations should exercise caution and follow best practices to ensure that the right accounts are targeted for deletion.


Cripsa Inc's "Delete User" API simplifies the process of managing user accounts, aligning with modern security and data management requirements. This robust feature provides organizations with the control and flexibility needed to efficiently handle user data and maintain the integrity of their applications.


To Delete User, the API end point is as follows:


https://api.cripsa.com/v2/rbac/deleteuser

The payload of verify access token is as follows:


RBAC

Note: Please make sure that in the Header you are sending your own API Key which has been generated while creation of the project.


RBAC

The Postman Output is as follows:


RBAC

When utilizing Cripsa Inc's "Delete User" API to remove user accounts, it's important to exercise caution and follow best practices to ensure the security and integrity of your application and user data. Here are some precautions to take while using this API:


Authorization and Access Control: Ensure that only authorized personnel, such as administrators or specific roles, have access to the "Delete User" API. Implement appropriate access controls to prevent unauthorized or accidental deletions.


Confirmation Mechanism: Implement a confirmation mechanism before executing the deletion. This could involve requiring a secondary authentication factor or confirmation prompt from administrators to prevent accidental or unauthorized account deletions.


Audit Trail: Maintain a detailed audit trail of user deletions. Log relevant information such as the date, time, user requesting the deletion, and the reason for the deletion. This audit trail can help track and investigate any unusual or unauthorized activities.


User Communication: If possible, notify users or account owners about the impending deletion of their account. This can prevent misunderstandings, and users who still require access can reach out to prevent the deletion.


Testing and Sandbox Environment: Test the "Delete User" API thoroughly in a controlled environment before deploying it in a production setting. Utilize a sandbox environment to simulate account deletions and identify any potential issues.


Documentation and Training: Ensure that your team is well-informed about the proper use of the "Delete User" API. Provide comprehensive documentation and training to administrators who have access to this functionality.


Compliance and Regulations: If your organization operates under specific regulatory frameworks, ensure that the user deletion process aligns with compliance requirements. Follow legal guidelines regarding data retention and deletion.


By taking these precautions, you can effectively leverage Cripsa Inc's "Delete User" API while minimizing risks and ensuring the security of your application's user data.


The reference of the API detail one can finds in the URL :


https://cripsa.com/rbac-delete-user