IAM in OCI
tags :
OCI construct #
Identity and Access Management (IAM) uses identity domains (Identity Domain in OCI) to provide identity and access management features such as authentication, single sign-on (SSO), and identity lifecycle management for Oracle Cloud as well as for Oracle and non-Oracle applications, whether SaaS, cloud hosted, or on premises. ref
AuthN and AuthZ #
Principal is an abstraction for user and machine resource (machine ID)
- policies are defined at group levels.
Tenancy Setup #
MFA: something you know and something you have
Policies in OCI
OAuth in OCI #
Vocabulary #
Principal #
Principal is an abstraction for user and machine resource (machine ID)
Adding Google IdP #
Pros and Cons of role based access control (RBAC) using IAM with API Gateway in OCI vs Django Middleware #
Question: I am using oci api gateway and controlling access by making api accessible only if they have scopes of jwt. in the deployment I am using Claims validation to control the access to the apis. After the access control implementation, I want to implement roles based access. I think have these options: 1. implement role based access control at api gateway level 2. implement it in custom middleware of django by reading the jwt token, parse scopes and claims and associate it the request object and use it in code to control the access. 3. implement role based access control in the django model and store the roles in django database. I want simpler archtecture and leverage OCI IAM. what are pros and cons of each approach and what is best possible approach.
Answer by ChatGPT Implementing role-based access control (RBAC) in your system, especially when using OCI API Gateway and Django, can be approached in various ways, each with its own set of advantages and challenges. Let’s evaluate the three options you mentioned:
Role-Based Access Control at API Gateway Level #
Pros: #
Centralized Security Policy: Managing access control at the gateway level allows for a centralized security policy, which can be easier to manage and audit. Reduced Load on Backend: By handling access control at the gateway, requests that don’t meet the necessary criteria are blocked before reaching the backend, reducing the load. Consistency Across Services: If you have multiple backend services, implementing RBAC at the gateway ensures consistent access control across all of them.
Cons: #
Limited Flexibility: The API Gateway may offer limited flexibility in terms of complex access control rules compared to application-level controls. Potential for Increased Complexity: Managing a large number of rules and roles at the gateway can become complex, especially if the access needs are intricate.
Role-Based Access Control in Custom Middleware of Django #
Pros: #
Fine-Grained Control: Implementing RBAC in Django allows for more nuanced and complex rules, tailored to the specific needs of your application. Leveraging Django’s Ecosystem: Django’s robust ecosystem and tools can be used to manage and enforce access control, benefiting from Django’s security features. Context-Aware Decisions: The middleware can make decisions based on the full context of the request, which might not be possible at the gateway level.
Cons: #
Increased Load on Backend: All requests, even unauthorized ones, reach the backend, increasing the load. Maintenance Overhead: Requires additional code and maintenance within the Django application, potentially increasing the complexity of your application code. Dependency on Token Validity: The system is heavily reliant on the JWT token’s validity and structure, requiring careful management.
Role-Based Access Control in the Django Model #
Pros: #
Integration with Django’s ORM: Leveraging Django models for RBAC allows for seamless integration with Django’s ORM and existing data structures. Database-Driven: Storing roles in the database can offer flexibility in managing and querying role assignments and access rules. Auditing and Traceability: Changes to roles and permissions are stored in the database, which can be beneficial for auditing and traceability.
Cons: #
Performance Considerations: Database queries for access control can add overhead to request processing. Complexity in Syncing with IAM: If roles are managed in both Django and OCI IAM, keeping them in sync can be challenging. Potential Redundancy: If similar access control mechanisms are implemented at the API gateway, this could lead to redundancy and increased maintenance.
Best Approach #
The best approach depends on your specific requirements, but here are some general guidelines:
Leverage IAM in OCI as Much as Possible: If OCI IAM can handle most of your access control needs, leveraging it reduces complexity in your application code. Use OCI IAM for broad, high-level access control, and complement it with more fine-grained control in your application as needed.
- Use Django Middleware for Complex, Application-Specific Rules: If you need complex, context-aware access control that cannot be efficiently handled by OCI IAM, implementing this logic in Django middleware is a good option.
Avoid Storing Roles in the Django Database Unless Necessary: This approach is typically more complex and should only be used if you have specific requirements that cannot be met by the other two methods.
In summary, a combination of OCI IAM for high-level access control and Django middleware for more nuanced, application-specific rules often provides a good balance between simplicity, flexibility, and maintainability.
Enabling Passwordless Authentication #
Passkeys #
Creating a Self-Registration Profile #
constructing URL #
Creating Hosted Sign-In page with Custom HTML page #
Limited set HTML tags and attributes are allowed here #
A limited set of HTML tags is available. #
div img image label input h1 h2 h3 span style
A limited set of style properties is available. #
align-items: background-color: background: border-radius: border: box-shadow: content: display: height: justify-content: left: margin-top: margin: max-height: max-width: min-height: padding-left: padding-right: padding: position: text-align: top: width:
API rate limiting #
ref how many API call can be made per/sec for IAM, AuthN and for token refresh
IAM pricing #
https://www.oracle.com/security/cloud-security/pricing/#iam first 1000 tokens, refresh + access token, are free every month.
- it is possible to increase expiry time of the JWT token and refresh token
- refresh token expiry time
- jwt token time manupulation, EXPIRATION_TIME_CLAIM
- token expiry table
Specified in the token request by sending
urn:opc:resource:expiry=<seconds>=in the scope parameter.