API Visibility Support about apk HOT 3 CLOSED

Meeting Notes (06/10/2023)

• The scope of this feature is to add visibility support for both backoffice and devportal. Implementation will start with adding devportal visibility first.
  • backoffice visibility : access control, defines who can edit the API
  • devportal visibility : defines who can view/subscribe the API
• No need to store group/role information on APK side, these will be extracted from a predefined claim that can be configured in the OAuth Provider.
• When adding APIs user should mention the roles/groups the API will be visible on backoffice and devportal. This information will be stored in the DB in API table's ARTIFACT JSONB field.
• In case the same group/role exist in two OAuth Providers, there should be a way to distinguish which OAuth Provider's group/role the API was meant to be visible to. Therefore, store both OAuth provider and group details when adding visible groups.

[1]. https://docs.google.com/document/d/1lKbO0dHrb3sfQpSf3_enTIJyfn2v4PHWLHM7OD-F2vU/edit#heading=h.m71y98ptsj6u

Thanks,
Sachini

from apk.

Status Update (10/10/2023)

• Got the backoffice internal API working and successfully added changes in backoffice to persist the devportal visibility settings in the DB artifact field. But ran into below issues when trying to fetch the API through backoffice and deportal APIs.
• Tried to invoke the backoffice and devportal /apis GET resources by passing the token in Authorization header. Even though the token has the required scope(apk:api:view) it still returned a 401.
• Added logs in JWTValidationInterceptor.bal and identified that the authorization token is not properly extracted, this was because the service expects the token to be passed in X-JWT-Assersion header instead.
• Even though I passed the token in X-JWT-Assertion still got below error while validating the token.

error: invalid Token {"code":900954,"message":"invalid Token","statusCode":401,"description":"invalid Token","moreInfo":{}}
	at wso2.apk_common_lib.0:validateJWT(JWTValidationInterceptor.bal:75)
	   wso2.apk_common_lib.0:$default$^^(JWTValidationInterceptor.bal:32)
cause: JWT contained invalid issuer name 'https://idp.am.wso2.com/token'
	at ballerina.jwt.2:prepareError(jwt_errors.bal:29)
	   ballerina.jwt.2:validateIssuer(jwt_validator.bal:569)
	   ballerina.jwt.2:validateJwtRecords(jwt_validator.bal:378)
	   ballerina.jwt.2:validateJwt(jwt_validator.bal:123)
	   ballerina.jwt.2:validate(jwt_validator.bal:114)
	   wso2.apk_common_lib.0:validateJWT(JWTValidationInterceptor.bal:47)
	   ... 1 more

• Had a discussion with Sampath, Krishan and TharinduA, backoffice API cannot be accessed directly the request should go through the gateway. Successfully invoked the /apis GET resource that way via below url
  https://default.gw.wso2.com:9095/api/backoffice/1.0.0/api/backoffice/apis
• Improved the devportal DAO query to filter based on visibility roles as well using JSONB operators[1]. For the moment I have hardcoded the list of roles of the current user, need to improve the logic to extract this info from the user context.

[1]. https://www.postgresql.org/docs/9.5/functions-json.html

from apk.

Status Update (12/10/2023)

• Added a claim mapping for groups. Internally the groups claim will be regarded as x-wso2-groups. Tested whether this claim value is passed to the ballerina service level through the authenticated user context (with both default IDP and asgardeo).
• In asgardeo the groups claim is passed in the JWT as a json[] during the sync up meeting it was decided to allow OauthProviders to pass groups as a json[] or a comma separated string, internal logic should be modified to handle both scenarios.
• Updated the parameterized queries to filter the APIs based on the visibility level and the user groups. Used arrayFlattenQuery to pass the groups list into the query.

[1]. https://lib.ballerina.io/ballerina/sql/latest

from apk.