List Group API does not authorize the service principal
Let's consider a typical scenario. A user "John" calls the Storage service API to query or write some records. After receiving this call, the Storage service triggers its authorization flow. It will call the List Group API of the entilement service to retrieve the groups John belongs.
In this scenario, the List Group API of Entitlement service has to deal with two kinds of principals.
- Storage service principals. This service principal is used for authorization between services. The Entitlement service should check who is the caller service and if it has the right to call its API. According to the Entilement documention (https://community.opengroup.org/osdu/documentation/-/wikis/OSDU-(C)/Design-and-Implementation/OpenDES-API-Specifications/Documentation/core-services/EntitlementsService#authorizing-calls-to-serviceapibackend) , the token of the caller service should be provided in Authorizaiton header and storage@instance.osdu.opengroup.org.iam.gserviceaccount.com should be added to service.entitlements.user@instance.osdu.opengroup.org.
- End user principals (John in this example), which is included in x-user-id header. Storage service is asking for groups John belongs. After successful authorization of Storage service, Entitlement service should queries the cache or database to return the groups John belongs.
But in the current implementation, I see the following issues.
- The Entitlement only relies on x-user-id header, both for service authorization and group query of the end user. The _isAuthorized _method of org.opengroup.osdu.entitlements.v2.auth.AuthorizationServiceEntitlements extract the principal from x-user-id header. This is not consistent with the design principle in the documentation. The Service principal is expected to used for authorizaiton between service, not the end user identity. If this issue is not fixed, every user should be a member of service.entitlements.user group in order to use OSDU services, which is not consistent with the documentation. In the documentation, storage@instance.osdu.opengroup.org.iam.gserviceaccount.com should be added to service.entitlements.user@instance.osdu.opengroup.org, not the end users. I agree with the way in the documentation. It is a bad design if every user has to be a member of service.entitlements.user group to use OSDU services.
- When Storage service calls List Group API of Entitlement service, it just forwards the header of the original API call, which means the List Group API call does not contains the service principal token of Storage service. Even Entitlement service has the correct logic for service authorization, if other services don't carry their service principal token in the API header, it is not possible to do service authorization. So this issue involves not only Entitlement service, but also other services.
I hope the Entitlement service could clearly differentiate the service principal token and user identity in its API documentation and use these two kinds of principals in the right way.
Maybe I have the wrong understanding. Could someone clarify this point for me? Thanks.