Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

For the slide deck on RBAC and implementation design, please check out - https://docs.google.com/presentation/d/1wNp1re47Isc_BX_wZWPjmJkOgnSqrlfhiNKRqJrirFE/edit#slide=id.p

...

edit?usp=sharing

Design:

  • Use OPA and Envoy as sidecars in backend microservices for authorization

  • A program which can convert the json schema definitions to OPA rego code

  • Sample schema definition (Work in progress, but the design is more or less as it looks below, some parts of the json keys can change to make more meaningful naming convention)

Schema in YAML
  • Token structure

--- - name: createContent uris
Code Block
languageyaml
json
{
  "aud": "/content/v1/create"
  upstream_url: http://knowledge-mw:5000/v1/content/create
  role_check:
    config.allowed_roles:
    - CONTENT_CREATOR
    - COURSE_CREATOR
  org_check:
    config.look_in:
    - body
    - header
    config.operator: and
    config.body: request.content.createdFor[*]
    config.header: X-Org-Id
  owner_check:
    config.look_in:
    - header
    config.header: X-User-Id
Schema in JSON
Code Block
languagejson
[
  {
    "name": "createContenthttps://sunbirded.org/auth/realms/sunbird",
  "sub": "f:229738b7-253c-4adf-9673-a857ppb86999:gca2925f-1qqq-4654-9177-fece3fd6afc9",
  "roles": [
    {
      "role": "BOOK_CREATOR",
      "scope": [
        {
          "organisationId": "0127134797703392110"
        }
      ]
    },
    {
      "role": "CONTENT_CREATOR",
      "urisscope": "/content/v1/create", [
     "upstream_url": "http://knowledge-mw:5000/v1/content/create",  {
  "role_check": {       "config.allowed_rolesorganisationId": ["0127134797703392110"
        "CONTENT_CREATOR",}
      ]
 "COURSE_CREATOR"   },
   ] {
   },    "role": "orgCONTENT_checkREVIEWER": {,
      "config.look_inscope": [
        {
          "body","organisationId": "0127134797703392110"
        "header"}
      ]
    },
    {
 "config.operator     "role": "andCOURSE_MENTOR",
      "config.bodyscope": "request.content.createdFor[*]",[
        {
          "config.headerorganisationId": "X-Org-Id0127134797703392110"
        }
      ]
    },
    {
      "owner_checkrole": {"ORG_MODERATOR",
      "config.look_inscope": [
        "header"
  {
   ],       "config.headerorganisationId": "X-User-Id0127134797703392110"
        }
     }
]
  • Schema can use the config.operator or can omit. The config.operator takes and or values which signify AND and ORoperation. If AND is used, then both keys are checked against the token and both need to match, if OR is used, then one of the key should match in the token

  • For a given check, the schema will not allow both AND OR operation to be used (example a && b || c). These type of checks will be treated as custom checks and will be directly implemented in rego. But these will work aa || bb || cc aa && bb && cc

  • Sample token structure

Code Block
languagejson
{
  "iss": "mykey",
  "aud": "project-sunbird-stage-client",
  "sub": "7e726898-0635-44cf-81ff-3b3a889c8dba",
  "typ": "Bearer",
  "exp": 1622744532,
  "iat": 1622658132,
  "roles": [ ]
    },
    {
      "role": "PROGRAM_DESIGNER",
      "scope": [
        {
          "scopeorganisationId": [ "0127134797703392110"
        },
        {
          "orgIdorganisationId": "012698787975036928100127134797703392110"
        }
      ],
    },
 "role": "COURSE_CREATOR"  {
  },     {"role": "REPORT_ADMIN",
      "scope": [
        {
          "orgIdorganisationId": "ORG_0010127134797703392110"
        },
      ]
   { },
    {
      "orgIdrole": "ORG_002"PUBLIC",
      "scope": []
    }
  ],
   ]"iss": "https://sunbirded.org/auth/realms/sunbird",
  "name": "Demo",
  "roletyp": "BOOK_CREATORBearer",
  "exp": 1640408569,
}  "iat": ]1640322173
}

Design disucssion that is yet to be signed off / agreed

New

...

flow on Portal and Mobile for anonymous and logged sessions

...

  • The portal and mobile both will do a recaptcha check and pass the recaptcha response to backend for verification (portal backend in case of portal, android recapthca check in case of mobile)

  • Once recaptcha response is verified, an API call is made for anonymous session to fetch a token for the user

  • As of now we will allow only the portal and mobile app to invoke these register APIs on behalf of the user. The register API is protected by a JWT token that is injected only in mobile and portal

  • These tokens (which are issued to portal and mobile on behalf of the user) will have a higher rate limit (maybe 500 per hour)

  • A anonymous user can also directly obtain a token, how to do that is mentioned somewhere below in this post, but such token will have a very low ratelimit (maybe like 100 per hour)

  • Kong ACL’s will be removed as we will not require any ACL checks, the API authroriztion check will be handled by OPA and Envoy sidecars

...

  • Any external system that requires access to API’s, can sigup as an user on Sunbird and then use one of the mentioned flows to generate access token

  • API access as usual will be based on the role of the user account on Sunbird

  • Any special API access can be granted by Sunbird admin by assigning the appropriate roles on the system

  • If the external system requires user context API’s for other users, then they can authenticate on Sunbird as the user and then use the user specific token for any use cases involved in their end (similar to VDN authentication)

  • We can also have a button on the portal UI to get the access token after login (similar to the ops support tool)

...

External systems can obtain a token as anonymous

...