JMJ CLOUD
  • Home
  • Projects
  • Blog
  • About Us
  • Contact Us

Our Blog

Using Roles and Privileges to fine tune access to ORDS Web Services

6/6/2019

0 Comments

 

Introduction

ORDS Logo
​Oracle REST Data Services (ORDS) provides many options for authenticating users. These include OAuth client, APEX User, Database Schema User and OS User. While it is important to ensure your ORDS web services are secured, you also need to consider what a client has access to once authenticated. As a quick reminder, authentication confirms your identity and allows you into the system, authorization decides what you can do once you are in. In this post, I will dive into roles and privileges and explain their part in authorizing access to ORDS web services for OAuth clients.

Overview

​Let’s start with a diagram to show how roles and privileges fit into the overall OAuth security model for ORDS.
Picture
A role acts as the link between one or more users and one or more privileges. You assign a role to one or more OAuth clients.
 
A privilege details what is secured by that privilege. When creating a privilege, you can secure either an entire module or secure based on URL patterns.
 
A URL pattern is part of the full URL for a web service or group of web services. If you have a module called ‘ev’ then you can secure all services in that module using the URL pattern ‘/ev/*’.

Example

Take the following three modules in an ORDS enabled schema called ‘XXORDS’.
Picture
Let's say we want to do achieve the following:
  • Allow services in the twillio module to be completely open (i.e. no authentication)
  • Protect the 'utils' and 'ev' modules
  • Allow the OAuth client ‘ADMIN_CLIENT’ access to any services in the 'utils' and 'ev' modules
  • Allow the OAuth client ‘EV_CLIENT’ access to services in the 'ev' module
 
Note: Prior to creating any privileges, all of your ORDS web services will be publicly accessible.
 
Roles
Based on the above, we will need to create two roles ‘ADMIN_ROLE’ and ‘EV_USER_ROLE’.

    

Privileges

We will also need to create two privileges. One to protect web services in the ‘ev’ module and one to protect web services in the ‘utils’ module.

Privilege 1 - EV_DATA_ACCESS
While creating this privilege, we will at the same time, link the privilege to both the 'EV_USER_ROLE' and the 'ADMIN_ROLE' roles. An OAuth client associated with either of these roles will be able to call the charge points web service:
  • https://example.com/ords/xxords/ev/charge_points

    
​Note: The pattern ‘/ev/*’ starts after the base URL for your ORDS enabled schema. In our case, this is anything after https://example.com/ords/xxords.
 
This is what the privilege looks like from SQL Developer:
ORDS Privilege
Privilege 2 - UTILS_DATA_ACCESS
While creating this privilege, we will only link the privilege to the 'ADMIN_ROLE' role. Only OAuth clients associated with this role will be able to call the 'dbinfo' web service:
  • https://example.com/ords/xxords/utils/dbinfo

    

​OAuth Clients

​If we stopped here, then there would be no way to access any web services in the ‘ev’ or ‘utils’ modules. The act of associating a privilege with a module or URL pattern effectively locks them down. We need to create OAuth clients and link them to the roles we created so that these clients can access web services in these modules.

OAuth Client 1 - EV_CLIENT
This script creates the OAuth client EV_CLIENT using the grant type ‘client_credentials’. It then grants the newly created client access to the EV_USER_ROLE. At this point the EV_CLIENT can call web services in the ‘ev’ module.

    
​OAuth Client 2 - ADMIN_CLIENT
This script creates the OAuth client ADMIN_CLIENT using the grant type ‘client_credentials’. It then grants the newly created client access to both the EV_USER_ROLE and the ADMIN_ROLE. At this point the ADMIN_CLIENT can call web services in the ‘ev’ and ‘utils’ modules.

    

Conclusion

In this post, I demonstrated how to use roles and privileges to provide fine grained access to your ORDS web services. ​​This is important when ensuring OAuth clients only have access to the web services they are supposed to. Unless your web service has to be public (e.g. if it is a Web-hook) then you should seriously consider adding OAuth security. 

Click here for more on OAuth security in ORDS.

Author

Jon Dixon (Co-Founder JMJ Cloud)

0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    RSS Feed

    Popular Posts

    - APEX Dog Food
    - Cloud ERP & APEX Mashup
    - Modernizing EBS with APEX
    - Easy APEX_WEB_SERVICE
    - Running APEX in RDS
    - ORDS What & Why?

    Categories

    All
    APEX
    AWS
    Fusion Cloud ERP
    INTEGRATION
    OCI
    ORDS
    PaaS
    RAD
    REST
    SOAP

    Archives

    January 2021
    October 2020
    September 2020
    June 2020
    May 2020
    April 2020
    February 2020
    January 2020
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    September 2017
    August 2017
    July 2017
    June 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016

Company

About
Contact
Blog
  • Home
  • Projects
  • Blog
  • About Us
  • Contact Us