Microsoft Graph API setup with Delegated Permissions

[COS]

Hi all,

We're currently trying to implement Microsoft Graph API to use in our workflows, however we can't seem to work out what exactly we're doing wrong.

Due to security reasons, we're not allowed to grant Blue Prism (V6.6) the Application Permission required to perform certain actions, so using Delegated Permission is the only way to go.

Things to consider for our use case:

- We work in a Citrix environment using VM's;
- For audit reasons, each process has its own robot user account which we use to log into the VM's via SSO;
- All robot user accounts (30+) have been exempt from MFA/2FA, so this shouldn't be an issue;

We've followed the documentation and set all prerequisites:

- Created an App Registration in our Azure AD;
- Set the API permissions (Files.ReadWrite.All and Sites.ReadWrite.All);

- Imported the Microsoft Graph – Authentication object release file

When using the action "Get Delegated Access Token" with mandatory parameters, we are unable to get a successful response back:

 

The only response we get is either a bad response ("The remote server returned an error: (400) Bad Request." or "(401) Unauthorized"). 

In the AD logs, we get a few more detailed exception details, but they don't really help us figuring out what the issue is. Without changing the credentials, we get a mix of errors varying from "admin consent required", "invalid credentials" and "account locked"... We're sure every parameter contains the right value (username/password/tenant_id/client_id/client_secret are valid).

I guess my question is, are we missing something in our setup? Or is the "Admin consent required" part the key issue here?

The funny thing is, when using the action "Get Application Access Token", we are able to retrieve a token, even though we have not given BP Application Permissions. So I'm guessing this is a token without any permissions? Because said token didn't allow us to use other API's (such as SharePoint), when we tested it just to be sure.

[ewilson]

Hi Carla,

​Admin consent is the key here. When trying to use delegated permissions the typical process is for the human user to receive a pop-up in a browser advising them that an application is requesting permission to work on their behalf. In this case, you're not going to have a human sitting around waiting to grant the delegated permission, so you have to take care of it up front. To do that, you need to have your admin go into the Application Registration definition and then API Permissions within the Azure Console. There, they need to select the Grant admin consent for [YOUR AZURE TENANT NAME] option (see below screenshot). 


Cheers,
Eric

[COS]

@ewilson

We have already granted consent as you've suggested, however this hasn't changed anything unfortunately... It's still giving us the same error responses. 

​

When using the user consent URL (same contents of GET request, but as a URL), we get the following message ("admin consent required") for that particular user account?

[ewilson]

From the Azure Active Directory console go to Users -> [Robot Username] -> Applications. Do you see the name of the associated Application Registration listed for the user?



Cheers,
Eric

[COS]

Hi, @ewilson​,

Yes, we have done as you suggested:

However this still hasn't wielded any results... 

[ewilson]

Hmm, it seems that you've covered all the bases. I would suggest double checking your Client ID and Client Secret values. Make sure you don't have any added white space at the beginning or end of either of them. Since you're trying to get a delegated token you also need to verify the username and password. Again, ensure that there's no extra whitespace include. There was a post on the here where someone determined that if the password included a ampersand (i.e. & ) that it would cause problems. 

Cheers,
Eric ​​

[COS]

Hi @ewilson,

Client ID and Client Secret are correct, since we've also tested them for while testing Application Permissions and we were successful in retrieving a valid token. So the problem seems to be with Delegated Permissions after all.

One thing that shouldn't be relevant, but worth mentioning, is that the user which is signed into the VM, is not the same user used to log into BP (so robot user is logged into the VM via SSO, en developer account is used to sign into BP app).

We've also checked Username and Password combinations, and specifically chose a robot user with no special characters in the password. Stepping into the action itself shows exactly how the call is made and in doing that we've confirmed they're all values are indeed correct and there are no whitespaces, etc.

Should we maybe issue a ticket with Microsoft and see if there's anything they can do? I'm unsure if the issue we're facing is BP or MS/Azure related.  

​

[ewilson]

Before you open a ticket with Microsoft I'd try recreating the issue with Postman or cURL. If you see the same behavior, it's most likely something on the Microsoft config side. If it works fine in either of those other tools then I'd say it's something in the BP config.

Here's an article from Microsoft about how to use Postman to work with Graph.

https://learn.microsoft.com/en-us/graph/use-postman

Cheers,
Eric

[EslamGhandour]

Hi Carla, 

We've been facing this issue on our end for a long time as well. It was related the security of the company as by passing username and password as an input, it was being blocked by the company. We had to follow latest authentication methods without passing the username and password in the request. 

We overcame that by getting token for SSO, which will be solving your problem based on the scenarios you mentioned. You can use a VBO that is available on BP Digital exchange following this link, Function for Microsoft Authentication Library (MSAL) - 2.1.0

This authenticates the logged in user using MSAL. Just ensure that you enable the SSO for Windows Integrated Auth Flow on your application setup in AzureAD. You can find the toggle button for it under your APP, then choose Authentication from the left panel. The toggle button will be in the end of the page.

Doing those steps solved the issue for us, I hope it will help you.

[COS]

Hi @EslamGhandour

Thanks for the suggestion​! How did you find out that this was what was causing problems?

Correct me if I'm wrong please:

So after retrieving an access token, it sounds a bit like the action "Get Delegated Access Token" in the Microsoft Graph - Authentication VBO is either no longer needed (meaning we can pass the token we retrived using MSAL to the Sharepoint VBO for example to perform any action the user is allowed to do), or that its request body needs to be modified since it uses username, password en 'password' type grant?