ORDS, including SODA for REST, uses role-based access control, to secure services. The roles and privileges you need for SODA for REST are described here.
You should be familiar with the ORDS security features before reading this section. See Oracle REST Data Services Installation, Configuration, and Development Guide for the relevant information.
SODA_APP must be granted to database users before they can use REST SODA. In addition, when a schema is enabled in ORDS using
ords.enable_schema, a privilege is created such that only users with the application-server role
SODA Developer can access the service. Specifically,
ords.enable_schema creates the following privilege mapping:
exec ords.create_role('SODA Developer'); exec ords.create_privilege(p_name => 'oracle.soda.privilege.developer', p_role_name => 'SODA Developer'); exec ords.create_privilege_mapping('oracle.soda.privilege.developer', '/soda/*');
This has the effect that, by default, a user must have the application-server role
SODA Developer to access the JSON document store.
You can also add custom privilege mappings. For example:
declare l_patterns owa.vc_arr; begin l_patterns(1) := '/soda/latest/employee'; l_patterns(2) := '/soda/latest/employee/*'; ords.create_role('EmployeeRole'); ords.create_privilege(p_name => 'EmployeePrivilege', p_role_name => 'EmployeeRole'); ords.create_privilege_mapping(p_privilege_name => 'EmployeePrivilege', p_patterns => l_patterns); commit; end;
This example creates a privilege mapping that specifies that only users with role
EmployeeRole can access the
When multiple privilege patterns apply to the same resource, the privilege with the most specific pattern overrides the others. For example, patterns
'/soda/*' both match the request URL,
'/soda/latest/employees/*' is more specific than
'/soda/*', only privilege
EmployeePrivilege applies to the request.
SODA_APP is an Oracle Database role.
SODA Developer is an application-server role.
ORDS supports many different authentication mechanisms. JSON document store REST services are intended to be used in server-to-server interactions. Therefore, two-legged OAuth (the client-credentials flow) is the recommended authentication mechanism to use with the JSON document store REST services. However, other mechanisms such as HTTP basic authentication, are also supported.
Security considerations for development and testing are presented.
You can disable security and allow anonymous access by removing the default privilege mapping:
exec ords.delete_privilege_mapping('oracle.soda.privilege.developer', '/soda/*')
However, Oracle does not recommend that you allow anonymous access in production systems. That would allow an unauthenticated user to read, update, or drop any collection.
You can also use command
ords.war user to create test users that have particular roles. For example (where new_password is a placeholder for the password for user
# Create user bob with role SODA Developer java -jar ords.war user bob "SODA Developer" # Access the JSON document store as user bob using basic authentication curl -u bob:new_password https://example.com/ords/scott/soda/latest/