Integrations and APIs for Service

Get Involved. Join the Conversation.

Topic

    Carl Bramblett
    Giving an Account Permissions to Access the REST APIAnswered
    Topic posted September 27, 2019 by Carl BramblettSilver Medal: 2,000+ Points, tagged REST 
    62 Views, 8 Comments
    Title:
    Giving an Account Permissions to Access the REST API
    Summary:
    What is the setting in the console that allows a user to access the REST API?
    Content:

    Hi,

    What is the setting to allow a user to access the REST API? We currently have one admin account that is able to do it, but wish to create a second one that will be used exclusively for automated scripts. As far as I can tell both accounts are identical (both admin accounts), but only one of them is able to use the API. The other account receives an error that they are not authorized.

     

    I'm sure it's a simple setting, but helping me locate it in the Oracle labyrinth would be greatly appreciated! :)

     

    Thanks, 

    Carl

    Code Snippet:

    Best Comment

    Allan Schrum

    The REST API is enabled for all accounts to use.

    Access can be controlled by IP Address so make sure that is properly set for your use cases.

    Accounts that are SSO-based cannot directly use REST because of the SSO process. Authentication for username/password (Basic), OAuth 2 (Bearer) and CX-Session (Session) is supported. Thus SSO-based accounts can use the other two methods that are available. A common use case is the use of REST via the BUI extension framework where the CX Session is available.

    If permissions are enabled for your site (config SERVER_ACCESS_CONTROL_ENABLED) then the capabilities for CRUD and various operations are controlled by permissions in that accounts profile. There are some oddities with this approach as there are some implied permissions (e.g. INCIDENT_VIEW implies CONTACT_VIEW as well). For custom objects the profile permissions are directly mapped to be accessed or modified by REST with no implied permissions.

    Comment

     

    • Tushar Gupta

      You need to authenticate the requests with one of the methods listed in the documentation. Refer the link below:

      https://docs.oracle.com/en/cloud/saas/service/18a/cxsvc/c_osvc_authentication_and_authorization.html

    • Carl Bramblett

      Hi Tushar, thank you for the quick response. I already have the basic auth working for one of my accounts. Let's call it account@mycompany.com. It's an admin account. I have created a second account, account2@mycompany.com. I have given it identical permission and yet when I use the basic auth technique it fails. Is there another setting I need to enable somewhere in the console?

      Thanks, Carl

    • Neil

      It's profile specific. In the profile permissions you can give 'Public SOAP API' access (see attached). This applies to the REST API also. 

      • Tushar Gupta

        Both the above permissions don't have any effect on the REST API authentications.

        • Neil

          Interesting, I just tested and you're right. I'm sure that used to work. Anyway I tested a profile with no permissions at all for anything and was still able to use the API to perform everything I tried. 

          • Sebastiaan Draaisma

            That sounds like a bug. You would think that permissions would decide which objects are available through API.
            I think it's worth creating an SR for this

            • Allan Schrum

              The REST API is enabled for all accounts to use.

              Access can be controlled by IP Address so make sure that is properly set for your use cases.

              Accounts that are SSO-based cannot directly use REST because of the SSO process. Authentication for username/password (Basic), OAuth 2 (Bearer) and CX-Session (Session) is supported. Thus SSO-based accounts can use the other two methods that are available. A common use case is the use of REST via the BUI extension framework where the CX Session is available.

              If permissions are enabled for your site (config SERVER_ACCESS_CONTROL_ENABLED) then the capabilities for CRUD and various operations are controlled by permissions in that accounts profile. There are some oddities with this approach as there are some implied permissions (e.g. INCIDENT_VIEW implies CONTACT_VIEW as well). For custom objects the profile permissions are directly mapped to be accessed or modified by REST with no implied permissions.

    • Carl Bramblett

      Hi all,

      Thank you for all the brilliant answers! I was able to get my second account to work after I simplified my password. Not sure if it was a result of user error, or if there are limitations on passwords in the API that aren't in the console. 

      Regardless, many thanks.

      Carl