REST API stopped working after upgrade to 7.1

dbeavon
Contributor

In the prior version of onestream we had configured AAD authentication, and we had a service principal that would be used to process REST API requests (aka the onestream "web api").  This service principal was simply to make all the requests for gettting data (cubeviews, adapters).

However since we upgraded to 7.1, the REST API has stopped working.  Whenever we present the onestream-web-api with the access token from AAD, it simply generates a bogus error: No Supported Authorization Provider Configured.

 

The reason the error seems bogus is because the AAD authentication provider is working for all interactive users.  It is only this particular AAD service principal that fails (the one associated with this REST api).

We noticed that the release notes for 7.1.0 says:

Microsoft is ending support for Azure Active Directory Authentication Library (ADAL) in December 2022. As a result, we have migrated to the Microsoft Authentication Library (MSAL) for authentication and authorization.

 

Based on this, I'm guessing there was a breaking change in the way that the REST API must be configured.  The upgrade did change the xml config, to some degree, but not in relation to this web API. 

Can someone please tell me where to find additional information that supports the unhelpful message that is sent to API clients: "No Supported Authorization Provider Configured"?  There has to be a log somewhere with the actual exception that is triggering this message.  The message is clearly not accurate as it stands.  We do have AAD identities working everywhere except in the web API.

 

Any help would be greatly appreciated.  I would guess that the developer(s) who worked on the migration from ADAL to MSAL would be able to help interpret this error message.

1 ACCEPTED SOLUTION

@HRunyon 

Sorry, I opened that question on behalf of an admin at my company.  I am a software developer and wasn't actually doing the configuration work myself. I don't have much visibility (poking around blindfolded).

 

I do know that we were able to get AAD authentication working again.  And 7.1.0 worked a lot more consistently with prior versions than I had expected (despite the scary notification that I shared from the release notes).

 

I also remember that our admins had to open a ticket with OneStream support to get this figured out.  We didn't do it all by ourselves.

 

From a developer standpoint, authentication for this OneStream REST API seemed strange.  The credentials of the remote REST client is a service-principal.  But the strange thing about this rest API is that OneStream uses the same service-principal credentials for the configuration on the server-side of things as well.  (It seemed like they don't have a firm grasp on oauth2 concepts.... or maybe it is implemented this way to be consistent with their other supported identity providers.)

View solution in original post

3 REPLIES 3

HRunyon
New Contributor III

I am also having the same issue, did you ever get this resolved? Thank you in advance.

@HRunyon 

Sorry, I opened that question on behalf of an admin at my company.  I am a software developer and wasn't actually doing the configuration work myself. I don't have much visibility (poking around blindfolded).

 

I do know that we were able to get AAD authentication working again.  And 7.1.0 worked a lot more consistently with prior versions than I had expected (despite the scary notification that I shared from the release notes).

 

I also remember that our admins had to open a ticket with OneStream support to get this figured out.  We didn't do it all by ourselves.

 

From a developer standpoint, authentication for this OneStream REST API seemed strange.  The credentials of the remote REST client is a service-principal.  But the strange thing about this rest API is that OneStream uses the same service-principal credentials for the configuration on the server-side of things as well.  (It seemed like they don't have a firm grasp on oauth2 concepts.... or maybe it is implemented this way to be consistent with their other supported identity providers.)

What was the solution?