For partners that build or integrate commercially available applications and service solutions with the Oracle Cloud Platform
For partners that provide implementation or managed services around Oracle Cloud Applications
Currently, I am making an API call to fetch Region Subscription List and if the call status is 200, I am assuming, he is a valid user. Is this the correct way of doing authentication?
Status 200 simply means "accepted" or "success"; you would receive a 401 or an explicit user error if your user cannot call the API. More info here:
https://docs.cloud.oracle.com/iaas/Content/API/References/apierrors.htm
https://docs.cloud.oracle.com/iaas/Content/API/Concepts/workrequests.htm
Thanks for the inputs. So, to conclude we can make any API call and if call status is 200 (Successs), user is authorized. Any API Call is fine?
Karthik,
Authorization in OCI is implemented via IAM policies. Each policy statement grants a specific user group the permission to perform a specific action (e.g., manage, inspect, delete) on a specific resource type, in a specific compartment.
For example, if an API request to delete a VCN in compartment A returns 403 (unauthorized), then it means that there's no policy statement that allows this user to delete VCNs in compartment X. That's it. The result of this API request doesn't give any indication of whether or not the user is authorized to perform any action on any other resource-compartment combination.
I wish we had a way to query and get all the permissions that a given user has. Unfortunately, that capability doesn't exist today.
I hope this helps.
Thanks for the valuable inputs @Kumar. So instead of making an API on specific resource type in a compartment, can i make API call on global resources (like Compartment, ListRegionSubscriptions) to check if he is a valid user?
I also agree that for resource type specific calls, he may or may not be authorized as per the policies.
Karthik,
You're welcome!
Note that the policy syntax supports defining permissions at a very granular level:
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
For what you call "global" resources (e.g., compartments), the location would be the tenancy, not any specific compartment.
Say you define the following policy:
Allow group mygroup to manage compartments in tenancy
The users in mygroup can create, inspect, read, and use any compartments in the tenancy. That's it. By itself, this policy doesn't grant the users in mygroup any other permission.
Thanks for the information. It seems Compartment API call has also policy limitations. Do ListRegionSubscriptions[ https://docs.cloud.oracle.com/iaas/api/#/en/identity/20160918/RegionSubscription/ListRegionSubscriptions ] has also any policy limitations? If not, this can be used to validate a user?
Per this doc: https://docs.cloud.oracle.com/iaas/Content/Identity/Tasks/managingregions.htm,
If you're in the Administrators group, then you have the required access to manage region subscriptions.
Once thing that every user can do is view their own user profile. Therefore you should find that this API call works for all authenticated users even without any explicit policies in effect:
https://identity.us-ashburn-1.oraclecloud.com/20160918/users/YOUR_USER_OCID_HERE
Find documentation for this method here: https://docs.cloud.oracle.com/iaas/api/#/en/identity/20160918/User/GetUser
Certainly, change out the API endpoint to the region of your preference.
Jon-Eric
Mythics, Inc.
Once thing that every user can do is view their own user profile. Therefore you should find that this API call works for all authenticated users even without any explicit policies in effect:
Find documentation for this method here: https://docs.cloud.oracle.com/iaas/api/#/en/identity/20160918/User/GetUser
Certainly, change out the API endpoint to the region of your preference.
Jon-Eric
Mythics, Inc.