Question

How can I implement SingleSignOn when connecting to RingCenral using ringcentral-csharp-client SDK?

  • 11 July 2018
  • 8 replies
  • 1004 views

How can I implement SingleSignOn when connecting to RingCenral using ringcentral-csharp-client SDK? We have an inhouse application which instantiates RCclient, in this stage of development we are connecting using main account credentials. Unfortunately we are running into API limits since the app may have many instances (up to 100) for each of our users.


We do not want to ask for RC credentials as we already have SingleSingOn using Office365 working.


Is there a way to make this work with RC connection programmatically?


8 replies

Hi Adam, I don't quite understand what you want to do here.

Is SingleSignOn a solution for the rate limit issue?  I don't think so. No matter how you sign on, you will have rate limit issue as long as you make too fast requests.

At if all your 100 instance share the same RC credentials, only 5 of them could have active access token at a time. That's a limitation of RC Rest API.



Our users sign in to the app using SingleSignOn. So we would like create a session with RC under their credentials (phoneNumber and password are used by ringcentral-csharp-client) in order to stay within the limits of tokens and APIs.
We don't want to ask users for their RC credentials.
Userlevel 1

Hi Adam,


Please read this article as it would guide you to setup SSO for your account users.

https://support.ringcentral.com/article/1149.html


Your frontend app (c# or what ever) will need to implement 3-legged authentication in order to login with SSO.


Hope this helps,

+ Phong

Our company has implemented SSO for RingCentral access. I also have a test application working with ringcentral-demos-oauth project which redirects to https://service.ringcentral.com.
User then logs in via SSO, but how do I get the token back?

Also, getting this error when running ringcentral-client-oauth project with "Blocked a frame with origin "http://localhost:8080"; from accessing a cross-origin frame." when expecting token to come back from https://service.ringcentral.com after successful SSO.
In order to do the 3-legged OAuth login flow, you will need to bring up a pop-up browser window and set the 3-legged OAuth URL there. For the security reason, the 3-legged OAuth flow should never happen inside an iframe, which has been explicitly blocked by x-frame-options. It's very similar to the login flow when you try to login this devcommunity.ringcentral.com app with Google ID, you will see the Google login page is brought up in a pop-up instead of being rendered in an iframe.

The above behavior will be enforced in the new version of login page, so for now, embedding "https://service.ringcentral.com" in an iframe will still work.

The problem you encountered with the error - "Blocked a frame with origin "http://localhost:8080"; from accessing a cross-origin frame." - might be the inconsistency of protocol, where your main page is using "http", but iframe is using "https".
Adam, did you ever get an answer.  We have a HUGE problem with this because we want to automate the download of call logs into the datawarehouse, but can obviously not use SSO since someone would have to "click" to make this happen.

Corey
I ended up going with a different solution, as even the SSO required the credentials then storing them locally for what our application needs. Instead of using one admin set of credentials and executing all API calls under it, then possibly running into the limits; we have 4 sets. These are the admins of our RC system. I monitor the API usage per minute, then when we get close to the limit, we switch to a new connection under another set of credentials in round-robin fashion. This is working fine as it rarely happens in peak times. Also, when we first connect to RingCentral, we cache all users and userPresence as reference of extension id's. We use this for processing of incoming event notifications.
Also, ringcentral-csharp-client is going to be extended soon to include values from the header. The header holds number of available API calls, so it will simplify some of my logic as I keep track of it now.

Reply