Page Comparison

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 codeSample 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)Token structure

{
  "aud": "https://sunbirded.org/auth/realms/sunbird",
  "apissub": ["f:229738b7-253c-4adf-9673-a857ppb86999:gca2925f-1qqq-4654-9177-fece3fd6afc9",
  "roles": [
  {  {
      "namerole": "createContentBOOK_CREATOR",

       "urisscope": "/content/v1/create", [
        {
          "upstream_urlorganisationId": "http://knowledge-mw:5000/v1/content/create",0127134797703392110"
        "checks":}
[      ]
    {},
    {
       "checkTyperole": "roleCheckCONTENT_CREATOR",
      "scope": [
    "key": "token",    {
          "tokenorganisationId": "CONTENT_CREATOR, COURSE_CREATOR"
0127134797703392110"
         },
      ]
   { },
    {
      "checkTyperole": "orgCheckCONTENT_REVIEWER",
      "scope": [
    "key": "body",    {
          "bodyorganisationId": "request.content.createdFor[*]"
0127134797703392110"
         },
      ]
   { },
    {
      "checkTyperole": "ownerCheckCOURSE_MENTOR",
      "scope": [
        {
   "key       "organisationId": "header || body",
 "0127134797703392110"
        }
      ]
   "body": "request.userId" },
    {
      "role": "header": "X-User-Id"ORG_MODERATOR",
      "scope": [
        {
  }         ]"organisationId": "0127134797703392110"
        }
      ]
    }

• Schema can use || , && or single keys. The || and && signify OR and AND operation. 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

• Sample token structure

{
  "iss": "mykey",
  "aud": "project-sunbird-stage-client",,
    {
      "useridrole": "7e726898-0635-44cf-81ff-3b3a889c8dbaPROGRAM_DESIGNER",
  "typ": "Bearer",   "expscope": 1622744532,[
  "iat": 1622658132,   "roles": [ {
   {       "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
}

...

• Addminutils will invoke the get user roles API and append the roles and orgs information to JWT token, sign it and then issue it to the user

Design disucssion that is work in progress

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, and 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 useeruser) 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

Internal communication between services

• Backend services can invoke APIs such as system APIs, metadata APIs etc anytime within the system (say backend batch job, Flink jobs, Samza jobs etc)

• The services will be either injected with a token that is accepted by all services (and also passes the OPA checks) OR they will be routed via a separate service like private ingress which will attach a token to the request and forward to the backend

• This token will have no expiry and can be used only for invoking the system, meta APIs

• Using this token, user context APIs cannot be invoked.

• User context APIs will always require a user token

...

• As a registered user on the system you can obtain access tokens to invoke APIs for use cases like development, bulk content creation etc

• There are two ways you can invoke the APIs

  • First option is to login on the system using Portal and use the connect.sid cookie for all your APIs via postman / curl. These APIs need to be routed via Portal endpoing endpoint and cannot use the /api endpoint

  • Second way is to obtain a token first from keycloak, then use the keycloak’s refresh token to obtain a new token from adminutils which will have your roles information. You can use the access token issued by adminutils to invoke APIs using the /api endpoints

• In either approach, what APIs you can access is decided by what roles you have on the system

...

• Note: Kong validating the Keycloak’s refresh token is not yet tested. But since the refresh token from keycloak is of type HS256, and we know the secret to be used to verify the HS256 signature and the iss to be used in Kong for validation (the domain), so we should be able to validate the keycloak token signature in kong also by onboarding a consumer with iss and the secret

External systems can obtain a token

• 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 that 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

• These are some special scenarios which we need to thinkPure anonymous access with higher rate limit

• In this design, anonymous access can only be access via done using the Portal / Mobile

• For other systems where they need anonymous APIs access, we can expose an open endpoint (rate limitted by IP) from where a token will be issued which can be used for anonymous access

• These will have very low rate limits to avoid APIs being access accessed unknowingly as telemetry data, streaming url etc, will go unnoticed

• This use case should be avoided if possible and APIs / tokens can be accessed / obtained only by signing up as a user on the system

...

• We should have more fine grained roles so we can have ensure a user gets only specific set of APIs and not a wider set of APIs

• Additional roles like below can be identified and introduced in the system

  • ORG_MANAGER

  • CONTENT_PUBLISHER etc

  A possible introduction of

• We can also introduce redis for storing rate limit values limits as this will be a true ratelimit, instead of the local pod based rate limits in Kong