Skip to main content

I see on the Directory Integration page that System for Cross-Domain Identity Management(SCIM) is an option. I also found that Azure Active Directory can leverage SCIM for user and group provisioning and de-provisioning. https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/use-scim-to-provision-users-and-groups I'd rather go this route if possible than setup Okta and use yet another product just to get directory integration working.


Has anyone done this successfully? I'm using https://platform.devtest.ringcentral.com/scim/v2/ as the Tenant URL for my application in Azure, and my Application Client Secret for the Secret Token, but I can't even get a test connection to work.


Any suggestions other than just use Okta?

Hi Everett,

Azure and RingCentral are working on an app that can do the user provisioning from Azure to RingCentral. Due to the resource constraint on the Azure side, They don't have a confirmed timeline yet.

Azure provides the ability to configure the "non app gallery" app by providing an one-time access token. However, since RingCentral access token can live for an hour, it's not really recommended to configure such an app to provision the users. 

Also, there will be some user guide doc prepared by product team when the app is ready. For example, RingCentral leverages the user's address to assign the purchased phone numbers. Azure provides the free-formed address fields. In order to have RingCentral assign the number accurately, the address attributes need to follow certain standard, such as SO 3166-2 - Country Codes, full state/county name, and correct city name, etc.
Hi Everett,

Correct, the non gallery app will stop working after 1 hour due to the expiration of access token. The real app will have the OAuth flow that keeps the refresh token to obtain the access token when it expires.

We originally targeted for Q2 of this year.


Hi @Alex Janes, Azure team is still working on the 3-legged OAuth flow to maintain the refresh/access token automatically. They had an initial release last month, but it seemed that they encountered some error and rolled it back. Hopefully, it could be fixed and released soon.

In the meanwhile, if you still want to use long-lived token approach, you can contact RingCentral support team to request one. Usually, a customized token can be valid for 3-6 months.

Again, Thanks for your patience

Hi @tony-li,

I've found Azure's OAuth to be highly functional with token refreshes (auth_code and access tokens).

What I've seen in RC's OAuth flows, ClientID/ClientSecret is not a supported flow type for obtaining an auth_code then access token.

Generally, ClientID+ClientSecret are base64 encoded together, then encrypted by the issuer (in this case the issuer is RC). That string constitutes the ClientSecret value issued by the Resource Provider, which Azure.Identity expects the configuring Admin person will put into the Client Secret field for OAuth setup (tracks for AzureAD.SCIM OAuth setup as well).

Just IMO.... I'm surprised MS would consider putting an auth_code (token), access token or even a refresh token as a configured, long-lived persisted value for an OAuth setup. That's what the OAuth spec defines the ClientSecret for.






Reply


Terms & ConditionsCookie settings