feat(flex): Cedar Security: Front Admin UI and Back End Config API

[kdhttps]

Implement the new cedarling integration. More Details https://github.com/GluuFederation/flex/wiki/AdminUI-Cedarling-Authorization-Design

graph LR
    %% Style definitions
    classDef green fill:#d5f0d5,stroke:#000,stroke-width:1px;
    classDef yellow fill:#fff2cc,stroke:#000,stroke-width:1px;
    classDef blue fill:#d9e8fb,stroke:#000,stroke-width:1px;
    classDef orange fill:#f9d5b3,stroke:#000,stroke-width:1px;

    %% Top level actors
    AUI -.->|Access APIs| CAB
    U["👥 Users"] -.->|Access components| AUI
    AD["👤 Admin"] -.->|Enable cedarling<br/>Add Policy store URL| CCP
    AD -.->|Manage policy store<br/>edit/delete schema| PA

    %% Admin UI Frontend
    subgraph AUI[Admin UI Frontend]
        CCP[Cedarling Config Page]
        CC[Cedarling Client<br/>- authz user request]
    end
    class AUI green

    %% Config API Backend
    subgraph CAB[Config API Backend]
        CCB[Cedarling Client<br/>- authz user request]
    end
    class CAB yellow

    %% Policy Authoring
    subgraph PA[Policy Authoring]
        ALPD[🧩 Agama Lab Policy Designer]
        GHR[💾 GitHub Repository]
        ALPD -.-> GHR
    end
    class PA blue

    %% Lock
    L["🔒 Lock"]
    class L orange

    %% Connections between UI & Backend
    CC -.->|Send Audit data| L
    CCB -.->|Send Audit Data| L

    %% Policy store fetch
    CCB -.->|Fetch policy store| GHR
    CC -.->|Fetch policy store| GHR

Issues

Please check below sub issues for details sub task

[duttarnab]

I am inspired with the clear wiki with HLD. I have few points to discuss:

1. I think Security will not exist under System and Monitoring because if we start using Cedarling for access control with the policy-store, we cannot map/unmap permissions to roles via the GUI and see their effect on Admin UI access control. The policy-store will only be responsible for GUI access control.

2. On the backend, the policy-store should also control the inclusion of scopes or capabilities in the access token, ensuring that the logged-in user can access only those config-api endpoints (invoked by the GUI) permitted by the policy-store.

3. We have already defined parent group and sub resources. I have a question here. System and monitoring has following sub-resources: Dashboard, Health, License, MAU, Settings, Security, Webhooks, Assests, AuditLogs. Now the Security Auditor will have following policy (mentioned below). How we will manage if customer want Security Auditor to have only read access to Dashboard,Health,License,MAU and read/write/delete access to all other sub-resources like Settings,Security,Webhooks,Assests,AuditLogs?

@id("AuditorCanManageSystemMonitoring")
permit(
principal in Gluu::Flex::AdminUI::Role::"auditor",
action in [Gluu::Flex::AdminUI::Action::"add",
Gluu::Flex::AdminUI::Action::"update",
Gluu::Flex::AdminUI::Action::"view",
Gluu::Flex::AdminUI::Action::"delete"],
resource is Gluu::Flex::AdminUI::SystemAndMonitoringResource
);

@kdhttps @nynymike

[duttarnab]

Few questions:

1. In diagram, I can see Cedarling client in Admin UI and also in Config Api. Why do we need cedarling client in both Admin UI and Config API? How processing the policies both at backend and and Frontend is required?
2. We need figure out how to implement below point:

 On the backend, the policy-store should also control the inclusion of scopes or capabilities in the access token, ensuring that the logged-in user can access only those config-api endpoints (invoked by the GUI) permitted by the policy-store.

3. Are we going to share any default policy-store with customer so that they can use it to create their policy-store in Agama-lab? If yes then how the default policy-store can be shared with each and every customers?

[kdhttps]

1. Yes, we need it in both cases. There is a high probability that the user can directly try to call APIs using an Admin-UI session or a token.
2. Currently, there are only RBAC policies, but I think making scope-based ABAC policies is also a good idea. I'll make some and share with you.
3. Yes, we are going to provide a default policy store. Please check the first 2 sub-issues. I have added a default policy store for both Admin-UI and config API.

[duttarnab]

Currently, there are only RBAC policies, but I think making scope-based ABAC policies is also a good idea. I'll make some and share with you.

Yes, if you share the policies then it will add clarity about the plan.

Yes, we need it in both cases. There is a high probability that the user can directly try to call APIs using an Admin-UI session or a token.

I think stepwise breakdown of this idea will provide more clarity, how you are thinking to implement this.

[kdhttps]

Yes, if you share the policies then it will add clarity about the plan.

Sure, I'll share.

I think stepwise breakdown of this idea will provide more clarity, how you are thinking to implement this.

I think I already added steps in the form of Sub Issues.