![]() Though it technically works for this use case, it does so by essentially using a “service account” so all REST calls your application makes are within the scope of a single UID. I’ll won’t go into much detail on this one because the folks behind OAuth 2.0 are suggesting the phase-out of the use of this flow ( source one) ( source two). ![]() Here, “flow” is a term used to describe the process for accessing a protected resource within the OAuth framework. There are two main “flows” available to make this happen. Any situation where you’d like to expose some content you’ve created in SAS Viya to a large scale of users, particularly those that wouldn’t have valid login credentials to your SAS Viya environment, fall in this category. In these cases, however, you do still want control over the endpoints/resources your app calls and which CRUD operations it performs on them. You don’t want the tokens returned by SAS Logon to your custom applications generating authorization decisions based on the individual using your application. ![]() General-scoped access tokensįirst, when I say “general-scoped access” here, I mean cases where you don’t want end users to have to log in (directly to SAS Viya, at least). If those topics are unfamiliar to you and you will be implementing this custom application registration, please take a look at the resources linked inline. ![]() Quick disclaimer: The rest of this post assumes you are familiar with the SAS Administration concepts of Custom Groups, granting access to SAS Content, and creating authorization rules. Now let’s go a bit deeper into the authorization flows for both scenarios. I also introduced the primary decision you need to make before you begin integrating your custom app into your SAS Viya environment: whether those access tokens will be scoped in the context of your application (general-scoped) or in the context of each logged-in user of your application (user-scoped). Administrators of your SAS Viya environment have complete control over the rules that determine the outcome of those decisions. The access tokens contain the necessary information SAS Viya will use to make authorization decisions for every call your app makes. I outlined the returned access tokens need to be included with the REST calls those custom apps make to SAS Viya endpoints and resources. Key takeaways from the previous postĪs a quick recap, in the last post I covered how to integrate custom-written applications with the SAS Viya platform using scoped access tokens from SAS Logon Manager. Then in the second part, I outlined the security frameworks and main integration points used to accomplish that. I began the series with an example of how a recent customer achieved value-add on top of their existing investments by building a custom app for their employees and embedding repeatable analytics from SAS Viya into it. This is the third installment of a series focused on discussing the secure integration of custom applications into your SAS Viya platform. This post was kindly contributed by SAS Users - go there to comment and to read the full post.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |