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
Design discussion that has been signed off / agreed upon as of date
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)
{
"apis": [
{
"name": "createContent",
"uris": "/content/v1/create",
"upstream_url": "http://knowledge-mw:5000/v1/content/create",
"checks": [
{
"checkType": "roleCheck",
"key": "token",
"token": "CONTENT_CREATOR, COURSE_CREATOR"
},
{
"checkType": "orgCheck",
"key": "body",
"body": "request.content.createdFor[*]"
},
{
"checkType": "ownerCheck",
"key": "header || body",
"body": "request.userId",
"header": "X-User-Id"
}
]
}
]
}
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 tokenSample token structure
{
"iss": "mykey",
"aud": "project-sunbird-stage-client",
"userid": "7e726898-0635-44cf-81ff-3b3a889c8dba",
"typ": "Bearer",
"exp": 1622744532,
"iat": 1622658132,
"roles": [
{
"scope": [
{
"orgId": "01269878797503692810"
}
],
"role": "COURSE_CREATOR"
},
{
"scope": [
{
"orgId": "ORG_001"
},
{
"orgId": "ORG_002"
}
],
"role": "BOOK_CREATOR"
}
]
}
Parser code (work in progress) - https://github.com/keshavprasadms/rego-go-parser
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 proposed 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
Once recaptcha response is verified, and 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
These tokens (which are issued to portal and mobile on behalf of the useer) 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)
Internal communication between services
Backend services can invoke APIs such as system APIs, metadata APIs etc anytime within the system (say backend batch job)
The services will be either injected with a token that is commonly accepted by all services (and also passes the OPA and envoy checks) OR they will be routed via a separate service like private ingress where the ingress service will have a token as a config which will be attached to the request before forwarding
This injected token will have no expiry