Name: Explaining Authorization APIs for CIAM for B2B in SAP Customer Data Cloud
Uploaded: 2024-8-12
Duration: 372 s
Description: This comprehensive video delves into the various types of authorization requests that can be made within the SAP Customer Data Cloud platform. It offers a detailed examination of the different authorization mechanisms available, providing viewers with a clear understanding of how to effectively leverage these requests to ensure secure access control and data management.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div><div><div><div><div><div>This comprehensive video delves into the various types of authorization requests that can be made within the SAP Customer Data Cloud platform. It offers a detailed examination of the different authorization mechanisms available, providing viewers with a clear understanding of how to effectively leverage these requests to ensure secure access control and data management.</div></div></div></div></div></div></div></div></div></div>

Explaining Authorization APIs for CIAM for B2B in SAP Customer Data Cloud

So now we're going to talk a little bit about the different types of authorization requests that you can make. So, basically there are two types of requests that you can make to understand whether someone should have access to something. And this is the authorization token  and the authorization request. And I'm going to go into these in a bit more detail in the coming slides.  The authorization token allows you to ask an open question. What assets can someone perform an action on for a specific asset template? So which websites can I access?  Which prescription categories I'm able to view? Which products can I buy?  Ultimately this is returning a list of things that you can access.  And therefore for this to work, assets have to be stored in the CIAM for B2B solution.  So virtual assets are not supported. We have to store instances of the assets in the platform.  And therefore this makes it suitable for smaller volumes of assets. So if we've got thousands of pharmaceutical drugs, it wouldn't make sense to maintain them as assets in the system.  And therefore the authorization token request, and wouldn't be appropriate. Generally speaking, the authorization token is a good mechanism for understanding authorization.  Where it's possible, we should try and call it with the known limitations that we've spoken about.  So just taking a little look at what that request and response actually looks like. At the top you can see a sample of the URL that you need to call. You need to pass a bearer token for authorization. On the left hand side, you can actually see the body of the request. And what we're passing there are details of the hook, which is the identity. So this is that the person's ID. And we're also passing the context of the organization in which we are making this request in. Obviously, someone can be associated to more than one organization. And they might have different access rights, depending on context that they're accessing it within.  And on the right hand side, we're seeing an example of the response. So, we're getting a list back of the attributes that we've requested back. So in this example on the right hand side, we've actually been returned a list of applications. And you can see this in the response.  Here is the template, the asset template of application or app.  And here is the action of view.  So we are saying this person can view applications with these with this information associated to it. So with the attributes of category commerce and category education.  Next looking at the authorization request. This allows you to ask a closed question. So can someone perform an action on this particular asset or on multiple assets? And the expectation is that you'll get a yes or no response to that question. So can I buy product X? Can I have a specific role in the commerce system? Can I view a psychiatric drugs category?  Now it allows you to pass in a single asset. So obviously that could be quite useful. For example, if someone is purchasing a high value item in a commerce system, we want to check that someone's actually got access to make that purchase.  Or it allows us to pass in a list of assets, multiple assets. And we can check for all of them whether someone should have access or not. This supports both assets that are stored as internal assets and virtual assets, where you're expected to pass in details of the assets with the request, which I'll show you on the next slide. So this is an example of the basic authorization request. Passing in a single asset and getting a yes or no response. Again, we can see the URL that we have to call. We have to also pass the authorization bearer header. And then we pass in the same details as before. So details of the person, their ID, and the organization that we're in the context of.  The difference to the token request that we saw before is here now, we're also passing in assets or instances of the assets to the request itself. And we need to do that because we're not storing them as internal assets. So we need to have a context as to what we're asking for access to. In this case, we're asking for context to a e-learning course that has an attribute associated to it of 'Shop'. And we're asking whether we can perform an action of view on that asset. And on the right-hand side, we can see the response. here I've been given access of 'allow'. If I didn't have access, it would show 'deny'.  Similar to that, we can actually create a detailed authorization request. And really the only difference is that we can pass in multiple assets into the body of the request. So on the left-hand side, you can see the same identity and organization data going in. But in this case, I've actually passed in two e-learning courses. One with a category of shop and one with the category of technical. And I'm asking whether I can view both of these courses. And on the right-hand side, you can see that I've actually been returned two lists. A list of approved assets and a list of rejected assets based on the policy that we've got defined. And in this case, it's saying I can view  the course with the category of 'shop'. But I cannot view the course with the category of technical.