Security

6 Security

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.

Database role SODA_APP must be granted to database users before they can use REST SODA. In addition, when a database schema (user account) 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 employee collection.

When multiple privilege patterns apply to the same resource, the privilege with the most specific pattern overrides the others. For example, patterns '/soda/latest/employees/*' and '/soda/*' both match the request URL, http://example.org/ords/quine/soda/latest/employee/id1.

Since '/soda/latest/employees/*' is more specific than '/soda/*', only privilege EmployeePrivilege applies to the request.

Note:

SODA_APP is an Oracle Database role. SODA Developer is an application-server role.

Note:

For greater security, configure ORDS to use HTTPS, and then use https, not http in your code, at least for production applications.

6.1 Authentication Mechanisms

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.

6.2 Security Considerations for Development and Testing

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. In this example, replace placeholders <user_name> and <password> with an appropriate user name and <password>:

# Create a user with role SODA Developer.
# (Be sure to replace placeholder <user_name> here.)
java -jar ords.war user <user_name> "SODA Developer"

# Access the JSON document store using basic authentication.
# (Be sure to replace placeholders <user_name> and <password> here.)
curl -u <user_name>:<password> https://example.com/ords/scott/soda/latest/

Parent topic: Security