EdenGuideReference

Identity and Access Management (IAM)

Eden's Identity and Access Management (IAM) system provides sophisticated, fine-grained access control for all resources within an organization. Built on the principle of least privilege, the IAM system allows organizations to precisely control who can access which resources and what actions they can perform, reducing security risks while enabling collaboration.

Access Control PhilosophyCopied!

Eden's access model is designed around a hierarchical approach where:

  • Access is explicitly granted, never implicitly assumed

  • Permissions cascade from organizations down to specific resources

  • More restrictive permissions always override less restrictive ones

  • Every API call is evaluated against the permission model

  • Actions are denied by default unless specifically permitted

This zero-trust approach ensures that users only have access to the resources they need to perform their job functions.

Access Levels ExplainedCopied!

Eden implements a role-based access control (RBAC) system with the following predefined access levels:

  • SuperAdmin:

    • The highest privilege level with complete control over the organization

    • Can modify organization state data and settings

    • Can add and remove administrators at all levels

    • Has unrestricted access to all resources and operations

    • Typically limited to a small number of trusted users

    • Responsible for critical security and governance decisions

  • Admin:

    • Organization-wide administrative capabilities

    • Can add and remove users with Write and Read access

    • Cannot modify SuperAdmin assignments

    • Can create, modify, and delete most resources

    • Responsible for day-to-day administration tasks

    • Can configure organization-wide settings and policies

  • Write:

    • Operational-level access for active users

    • Can create, modify, and execute resources (endpoints, templates, workflows)

    • Cannot modify user permissions or organization settings

    • Suitable for developers, integration specialists, and power users

    • Can perform most day-to-day operations within the system

  • Read:

    • View-only access to resources

    • Can see but not modify or execute resources

    • Useful for stakeholders who need visibility without operational capabilities

    • Appropriate for auditors, managers, and other oversight roles

    • Can use reporting and monitoring features

  • None:

    • No access to the organization or its resources

    • Default state for all users not explicitly assigned an access level

    • Used to explicitly document revoked access

Access Implementation DetailsCopied!

The IAM system works by evaluating three key factors for each API request:

  1. Who is making the request (user identity)

  2. What resource they're attempting to access

  3. How they're trying to interact with it (operation type)

This evaluation happens in real-time for every API call, ensuring consistent enforcement of access policies even as resources and permissions change.

Managing UsersCopied!

  • Create a User: POST /iam/users

    • Associates an existing user account with your organization

    • Assigns specific access levels to the user

    • The user must already exist in the identity system

    • Only SuperAdmins and Admins can create new user associations

    • Example request:

      POST /iam/users[  "Admin",  "jane.doe@example.com"]

  • Get User Details: GET /iam/users/{user}

    • Retrieves comprehensive information about a user within your organization

    • Includes access levels, resource permissions, and activity history

    • Useful for auditing and user management

    • Example response:

      {  "userId": "jane.doe@example.com",  "accessLevel": "Admin",  "created": "2025-01-15T14:22:10Z",  "lastActive": "2025-05-10T09:15:33Z",  "managedResources": {    "endpoints": 4,    "templates": 7,    "workflows": 2  }}

  • Delete a User: DELETE /iam/users/{user}

    • Removes a user's association with your organization

    • Does not delete the user account itself, only revokes access

    • Can be reinstated later if needed by creating a new user association

    • All user-specific permissions are immediately revoked

    • Resources created by the user remain but ownership may transfer

API ReferenceCopied!

Create User

  • URL: /iam/users

  • Method: POST

  • Headers Required: Authorization with JWT token

  • Request Body: User access level and email

  • Example Request:

    [  "Admin",  "jane.doe@example.com"]

  • Success Response: 200 OK with confirmation message

  • Example Response:

    {  "message": "User added successfully",  "userId": "jane.doe@example.com",  "accessLevel": "Admin"}

Get User

  • URL: /iam/users/{user}

  • Method: GET

  • Headers Required: Authorization with JWT token

  • URL Parameters:

    • user: The email or identifier of the user

  • Success Response: 200 OK with user details

  • Example Response:

    {  "userId": "jane.doe@example.com",  "accessLevel": "Admin",  "created": "2025-01-15T14:22:10Z",  "createdBy": "admin@example.com",  "lastModified": "2025-03-22T09:45:12Z",  "lastModifiedBy": "admin@example.com",  "lastActive": "2025-05-10T09:15:33Z",  "status": "active",  "managedResources": {    "endpoints": 4,    "templates": 7,    "workflows": 2  },  "activity": {    "lastLogin": "2025-05-10T09:15:33Z",    "loginCount": 42,    "lastOperations": [      {        "operation": "template.update",        "resource": "CustomerDataValidator",        "timestamp": "2025-05-10T09:20:15Z"      },      {        "operation": "workflow.run",        "resource": "OrderProcessing",        "timestamp": "2025-05-10T09:18:45Z"      }    ]  }}

Delete User

  • URL: /iam/users/{user}

  • Method: DELETE

  • Headers Required: Authorization with JWT token

  • URL Parameters:

    • user: The email or identifier of the user

  • Success Response: 200 OK with confirmation message

  • Example Response:

    {  "message": "User removed successfully",  "userId": "jane.doe@example.com"}

Access Control PatternsCopied!

Role-Based Access Model

Eden's access control system is built on a role-based model that maps common job functions to appropriate permission levels:

Role

Typical Access Level

Description

System Administrator

SuperAdmin

Technical administrators responsible for overall platform governance

Business Administrator

Admin

Business stakeholders who manage organization operations

Integration Developer

Write

Technical users who build and maintain integrations

Business Analyst

Write

Non-technical users who configure business processes

Stakeholder

Read

Users who need visibility but not operational capabilities

Auditor

Read

Compliance and oversight roles

Resource-Specific Permissions

While access levels provide a baseline, Eden also supports more granular permissions at the resource level:

Organization: Acme Corp
├── User: Jane (Admin)
│   └── Full access to all resources by default
├── User: Bob (Write)
│   ├── Default write access to most resources
│   ├── Elevated Admin access to specific Templates
│   └── Restricted Read-only access to Production Workflows
├── User: Alice (Read)
│   ├── Default read access to most resources
│   └── No access to sensitive customer data

Permission Inheritance and Overrides

Eden implements a hierarchical permission model where:

  1. Organization-level access provides the baseline

  2. Resource-specific permissions can override the baseline

  3. Explicit denials take precedence over any granted permissions

  4. Time-bound or conditional access can further restrict operations

IAM Best PracticesCopied!

When implementing your access control strategy in Eden:

  1. Follow the principle of least privilege

    • Assign the minimum access level needed for each user's function

    • Regularly review and adjust permissions as roles change

    • Start with restrictive permissions and gradually add access as needed

  2. Implement separation of duties

    • Divide critical functions among different users

    • Ensure no single user (except SuperAdmin) can control entire processes

    • Create control points requiring multiple approvers for sensitive operations

  3. Establish clear user management processes

    • Document procedures for onboarding, role changes, and offboarding

    • Create regular review cycles for access permissions

    • Implement formal approval workflows for privileged access

  4. Use granular permissions for sensitive operations

    • Limit SuperAdmin access to only those who absolutely require it

    • Consider creating custom roles for specialized functions

    • Implement additional safeguards for destructive operations

  5. Implement comprehensive logging and monitoring

    • Track all permission changes and access attempts

    • Set up alerts for suspicious activity