Security and Oracle Database Cloud - Database Schema Service

One of the key concerns for organizations as they move to a shared resource model on the Cloud is insuring the security of their data. Oracle Database Cloud - Database Schema Service, like the Oracle Database that is the foundation of the Database Cloud, has been created from the beginning with the utmost concern for security.


This section reviews several aspects of security and the Oracle Cloud:

  • The basic architecture of the security domains used with Oracle Cloud

  • Security measures that apply to the overall service

  • Security measures that apply to individual Database Schema Service

  • Application security options

  • Security options for RESTful Web Services that access Database Schema Service

Security Architecture

The Oracle Cloud uses a security architecture that includes different security domains and administrative and use privileges within a particular Oracle Database Cloud - Database Schema Service.


Security Domains

There are several different security domains used with the overall implementation of Oracle Database Cloud - Database Schema Service.

  • Accounts

  • Identity Domain

  • Database Schema Service


Each and every Database Schema Service is owned by an account. An account is the top level in the security hierarchy. The individual who initially sets up an Account is known as the Buyer. A Buyer is automatically an Account Administrator as an Account Administrator can assign themselves privileges at the Identity Domain and Service level.

When you initially sign up for Database Schema Service, you must have an user account. After you initially sign up for a service, you can grant the Account Administrator privilege to any other users. Any Account Administrator can remove the Account Administrator privilege from any other Account Administrator.

Account Administrators can see all services, PaaS or SaaS services, associated with an account.

Identity Domain

An Identity Domain is a pool of users. An account can have one or more Identity Domains, but each domain is separate and distinct. You must define an Identity Domain when you initially request an account, and the requester is given a username within the Identity Domain.

Identity Domain membership and privileges are defined on the Security page in My Services.

Members of an Identity Domain can have security roles for one or more of the Cloud Services associated with the Identity Domain. These roles described in more detail below.

Identity Domain Administrators can see all Database Schema Service associated with the Identity Domain, and can assign and remove all security roles associated with these services, including the Administrator role for any of the services.

Database Schema Service

Database Schema Service is an individual service within the Oracle Cloud. Data within an individual Database Schema Service is completely separated from data in all other services in the Oracle Cloud, as described in more detail below.

Database Schema Service administrators can define users for the services that they administer. Database Schema Service users can be defined on the Security page in My Services or within the Administration area of the development platform for the service itself. If a user is defined on the Security page in My Services, they must use this page to manage their profile; if a user is defined through the Administration area of the development platform, they must manage their profile through that platform. Administrators and developers for Database Schema Service must be defined on the Security page in My Services and given the appropriate security role.

Security Roles

There is an Administrator role at the Account, Identity Domain and Service levels. Administrators can grant this role at their level to other defined users.

There are three roles for each Oracle Database Cloud - Database Schema Service:

  • Service Administrator, who can create, modify and delete Database Schema Service users and their privileges, both on the Security page in My Services and the Administration area of Database Schema Service development platform.

  • Developers, who can use the development platform within Database Schema Service to create applications, but who cannot create, modify or delete users for that Database Schema Service.

  • End users, who can run applications within Database Schema Service.

When Database Schema Service is added to an Identity Domain, three individual roles which map to these levels are created within the Identity Domain. The Account Administrator and Identity Domain Administrator are automatically given the Service Administrator role for the initial Database Schema Service, but all other roles have to be explicitly assigned on the Security page in My Services.

Managing Users and Roles

All users and roles defined as part of the Cloud Identity Domain are administered on the Security page in My Services. On this page, an Identity Domain or Service administrator is allowed to add, delete and modify users, or to create, delete, assign or delete roles.

Identity Domain Administrators are allowed to access all users defined within their Identity Domain and their roles. Service Administrators only have access to the users defined for their Service, and users of a service can only modify their own user profile and reset their account password.

For more details, refer to Adding Users and Assigning Roles in Getting Started with Oracle Cloud.

Oracle Cloud Security Measures

All security is based on well-thought out and implemented practices and procedures. Oracle Database Cloud - Database Schema Service is implemented with rigorous security practices and procedures based on decades of experience.

The security processes used for the overall Oracle Cloud include secure access to data centers, annual security audits by third parties to insure regulatory security compliance and full auditing of the entire Cloud stack on a quarterly basis.

All data stored in the Oracle Cloud benefits from the use of Transparent Data Encryption. Transparent Data Encryption encrypts data stored on disk and in backups, protecting against unauthorized direct file access. The encryption and decryption of your data is handled automatically by the Oracle Database, so you do not have to add programmatic steps to use this powerful security feature.

The Oracle Cloud has to be protected against the introduction of malicious code which could harm all users. To enforce this level of protection while still allowing users to load data into their Database Schema Service, data loads are sent to a Secure FTP server, where they are scanned for viruses before the data in the files is loaded into the Database Schema Service using your database account information. With this approach, malicious data can never be loaded in such a way that it affects other accounts or breaches the security isolation. This two step process also automatically compresses the actual data to be loaded, reducing the time needed to upload data to the Oracle Cloud.

Oracle Database Cloud - Database Schema Service Security Measures

Oracle Database Cloud - Database Schema Service is built on a multi-tenant architecture, with database schemas providing the boundaries of tenant isolation. Schemas have been used in the Oracle Database as a method of separating data for decades.

To enforce and protect the absolute security of tenants of Database Schema Service, some standard Oracle features have been locked down.

For instance, access to any data dictionary view which allows a tenant to see the existence of other schemas has been prohibited. In addition, some SQL syntax is not allowed, such as GRANT or REVOKE, since accessing objects between one schema to another schema owner uses these options.

For a detailed list of syntax, objects and operations disallowed in Database Schema Service, see Oracle Database Cloud - Database Schema Service Features and Implementation Considerations.

Application Security Options

Your Oracle Database Cloud - Database Schema Service includes Oracle Application Express, which you can use to develop and deploy HTML-based applications through a declarative process. Oracle Application Express has been in production since 2004, with hundreds of thousands of enterprise applications deployed throughout the world.

There are many features of Oracle Application Express that help you to develop secure applications in your Database Schema Service.

Oracle Application Express supports several authentication schemes used to insure that a particular user is properly identified. Oracle Application Express gives developers the ability to use authorization schemes, which are ways of allowing access to specific pages, regions within pages or items within regions, based on user identity. As a developer, you always have access to the identity of a user, so you can implement procedural limitations based on user identity.

Although Oracle Application Express includes robust monitoring tools, you can add in procedural logic to log application and session specific information for further security analysis.

Oracle Application Express includes protection against cross-site scripting attacks by providing a way to reference values that automatically escapes special characters, which will not allow any type of script to be included in pages returned to users through Database Schema Service applications.

In addition, Oracle Application Express gives you the option to automatically protect navigational URLs from being maliciously modified. This option, referred to as Session State Protection, generates checksums which are included with any parameters passed as part of a URL to retrieve a page in an application. In addition, you can prevent a page from ever being accessed by a URL, only allowing access as the destination of a navigation link or branch from another page within the application.

Application Express also includes reports which allow you to rapidly see the security options in force for a particular application, and also to monitor usage of applications and individual pages in applications.

RESTful Web Service Security Options

Application Express also includes reports which allow you to rapidly see the security options in force for a particular application, and also to monitor usage of applications and individual pages in applications.


You can also specify security on a RESTful Web Service in several ways. These ways are different from the traditional method of using schema users to implement security. Oracle Database Cloud - Database Schema Service is based on a single schema, and all RESTful Web Services which access data in this schema are executed by the user who owns the schema. Without any specific security implementations on a RESTful Web Service, the services will return all data that satisfies an SQL statement or is collected by a PL/SQL block.

There are three ways you can add security to your RESTful Web Services:

  • Based on the application using the RESTful Web Service

  • Based on the identity of the user calling the RESTful Web Service

  • Based on logic implemented in the RESTful Web Service call itself


RESTful Services support two types of authentication: First party authentication and Third party authentication.

First party authentication is accomplished by the first-party authority, in this case the Application Express security system.

Third party authentication is accomplished by a third party authority, so the application requesting the authentication does not actually know the identity of the user.

Once a user is authenticated through either of these methods, you can limit authorization based on the identity of the user.

OAUTH2 Authentication

RESTful Web Services use the OAUTH2 model of authentication, as shown in the diagram below.

OAUTH2 authentication is one of the standard authentication flows used on the Internet. To understand how to implement application-based or user-based authentication, you need to understand how the OAUTH authentication process flow works.

OAUTH authentication requires two different tokens - a request token, which allows a client to request authorization, and an access token, which grants access to a specific user.

To limit access based on the application, you can grant access to the RESTful Web Services once authentication is complete. You can also use the username for specific authentication.

Logic-based Access

The method of implementing security described above grants access to one or more specific RESTful Web Services calls, similar to allowing a connection to a database. In traditional database security, access is granted based on the identity of the database user making the request. Since all RESTful Web Services in a specific Oracle Database Cloud - Database Schema Service are executed by the same database user, this option is not available for these Services.

In recognition of this architecture, the SQL command GRANT is not supported in Database Schema Service.

However, this does not mean that you cannot limit access to data based on user identity. The identity of a user is established through Database Schema Service authentication process, and this identity is available to developers as the :current_user bind variable, kept securely in the header of all RESTful Web Service requests.

You can use this value as part of a standard WHERE clause, which, for instance, could be used to limit the rows returned from a query to those for the same department as the current user. You could also use this value in more complex logic in either SQL or PL/SQL.