I am trying to obtain Admin consent for external application.
So I prepared link for an administrator of another company. Here is a link
As you can see:
scope=openid
admin_consent_scope=signature%20impersonation
But when administrator of target organization loggining in - he see the following screen
As you can see - it is requesting only "Obtain user information". But I expected to see permissions as in documetation:
After administrator clicked "Accept" - my app still gets an error consent_required when it generates JWT token.
Ok, had a call with Docusign support. They have a bit outdated specs.
The link should not have admin_consent_scope parameter and all scopes must be in scope parameter. Got it working.
Related
I am following the steps in this document
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/additional-claims?view=aspnetcore-6.0
I also downloaded their sample application here and set my google client id and client secret in my secrets.json.
https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/security/authentication/social/additional-claims/samples/6.x/ClaimsSample
The application runs fine. But I do not get the same output on the "My Claims" page as they have on their site. Specifically I am missing the access token.
Their results...
My Results...
If I am reading the documentation correctly that access token should be there due to this line
https://github.com/dotnet/AspNetCore.Docs/blob/7ae6a3f3f523c9a0b9d268e2b7ec37b11e7052a4/aspnetcore/security/authentication/social/additional-claims/samples/6.x/ClaimsSample/Program.cs#L19
I should also see a Token.TicketCreated value because of this line
https://github.com/dotnet/AspNetCore.Docs/blob/7ae6a3f3f523c9a0b9d268e2b7ec37b11e7052a4/aspnetcore/security/authentication/social/additional-claims/samples/6.x/ClaimsSample/Program.cs#L31
So why am I not seeing either of those?
The Home Page does show my picture and locale though so at least that part of the sample app is working. Any ideas?
Problem: How to authenticate in MS Graph using Azure AAD access token.
Current flow:
My web app has AAD configured with "Log in with AAD"
If I log into AAD my demo app is showing and if I go to https://******.azurewebsites.net/.auth/me
then I get the access_token.
What I tried:
So I tried a couple of things and this was the last, I copied the access_token as code and tried to send it, didn't work.
I'm searching for a solution to silently use the already logged-in user and call MS Graph.
The reason for the error is that you have used the wrong code. Don't try to send the access token as a code, you should request an authorization code in your browser.
https://login.microsoftonline.com/{tenant id}/oauth2/v2.0/authorize?
client_id={client id}
&response_type=code
&redirect_uri={redirect_uri}
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345
In addition, redirect_uri is also a required parameter.
For the already logged in user you need follow the below steps for access:
Make sure you have enable the allow access token for the register app as below
Write code to acquire access token for the for the logged in user Reference
Now you can pass this token in other successive call to get the result.
I have two accounts of DocuSign, both have the same config on the Setting section. But the first one even though expires of the trial still can send the envelopes. The second one gets invalid_request when I tried to get the JWT token base on client_id, user_id, and private_key.
Do we need to enable some config to allow it? Thanks in advance.
A couple of things:
Are you using a trial (login via www.docusign.net) or developer demo account (login via demo.docusign.net)? You should only use developer demo accounts while developing with DocuSign.
To get a free developer demo account click the link at the top right of the developer center page. Demo accounts do not expire, but their envelopes that are over 30 days old are automatically deleted.
invalid_request can be cause by a number of different issues. Additional information is available in the body of the response. Please see what it is and then edit your question to add the information.
Added
For JWT invalid_request errors, the recommended steps are:
Get the DocuSign code example running with JWT grant. For C#, this repo.
Once that works, you'll know that the problem is in your code, not in the settings of the integration key (the client id), the private key, etc.
Check that your computer's clock settings are correct--the timezone and the day/date. These are used by JWT.
Check that you are specifying a user's guid id to be impersonated. This is also referred to as a user's "API User Id"
Check the body of the API response for additional debugging information.
If you receive the error "consent_required", that is good news since it indicates that your JWT grant was correct, except that the person being impersonated hasn't yet granted consent to be impersonated. To fix, see this blog post.
With my outlook.com account I logged in to portal.azure.com and I created a new application. Microsoft has provided a sample app (daemon_console) for quick experiments (in QuickStart guide) and I followed steps provided for the sample app, the app automatically takes the application id and client secret you generated and updates the configuration JSON file (appsettings.json) with this info. I downloaded the code after these steps but when I run the sample app it throws the error "Authorization_IdentityNotFound".
Looks like it is able to fetch the token but following code is throwing the error:
var httpClient = new HttpClient();
var apiCaller = new ProtectedApiCallHelper(httpClient);
await apiCaller.CallWebApiAndProcessResultASync($"{config.ApiUrl}v1.0/users", result.AccessToken, Display);
Microsofts page has step to get Admin consent in two ways:
If you are a global administrator, go to API Permissions page select Grant admin consent for Enter_the_Tenant_Name_Here
Standard user
If you're a standard user of your tenant, then you need to ask a global administrator to grant admin consent for your application. To do this, give the following URL to your administrator:
https://login.microsoftonline.com/common/adminconsent?client_id=my apps client id
I have tried both these options. With the first option, I am able to grant the required permissions. But the issue still exists.
With the second option when I go to the suggested URL it fails with error:
"AADSTS500113: No reply address is registered for the application."
I think this should have been a straightforward process but somehow the app is not able to execute and fails with errors:
"code": "Authorization_IdentityNotFound",
"message": "The identity of the calling application could not be established.",
Please let me know if anyone has tried these steps and has managed to resolve this issue.
Note that I can run "https://graph.microsoft.com/v1.0/users" from graph explorer with my outlook.com account and it works perfectly fine.
I tested it, and at first I was running into the same issue,
its because of the common in the appsettings.json
replace the "Tenant": "common"
with "Tenant": "your Tenant ID",
You can get the tenant ID from the overview page of your app registration Directory (tenant) ID. After you do that, make sure you right click the project and click rebuild. because if I just do a normal run it had it cached and did not update it from common.
I am just starting out with the c# Google.Apis.Gmail.V1 classes and using a service account to read a mailbox.
My code works fine when I use the following snippet
ServiceAccountCredential credential = new ServiceAccountCredential(
new ServiceAccountCredential.Initializer(ServiceAccountEmailAddress)
{
User = "abc#test.domain.com",
Scopes = new[] { "https://www.googleapis.com/auth/gmail.readonly" }
}.FromCertificate(certificate));
With that code I can call the following successfully
if (credential.RequestAccessTokenAsync(CancellationToken.None).Result)
{
}
But I need to modify the email messages so I changed the scope from
https://www.googleapis.com/auth/gmail.readonly
to
https://www.googleapis.com/auth/gmail.modify
I now get an exception when requesting the access token
{"Error:\"unauthorized_client\", Description:\"Unauthorized client or scope in request.\", Uri:\"\""}
I have checked the service account (*.iam.gserviceaccount.com) in the Google Developers Console and I have tried all options for permissions including OWNER which should give me Full access to all resources but no joy.
I think I am just missing a simple step but I am unsure of where to look next.
TL;DR
I would read through this, but here is the short version. I know this is an older post, but hopefully it finds you!
If you have not updated/white-listed the service account's privileges/scopes in the Google Admin Console you will need to do that, make sure the domain has API access enabled, make sure the service account is setup properly, when creating the "certificate" object be aware its parameters so that it is being instantiated correctly, check the permissions on the account being impersonated and finally make sure you've made an appropriate Google Apps service account key (could have easily made an inappropriate key type.)
White-listing Google APIs in the Admin Console
This gives the Google Apps service account the abilityto use whatever scopes you provide in your Google Apps domain.
Login to the Google Apps Admin Console by using the following link.
https://admin.google.com/
The Google Apps user account must have sufficient privileges to modify domain related settings. It does not have to be the account used to create the Google Apps project in the developer console. If the account does not have privilege you will be directed to a completely different screen with no options to click on varying domain controlling web apps like "Security", "Roles", "Support", "Groups" and etc. Instead you'll dumped onto a page that shows things like "Gmail", "Drive", "Docs" and etc. that is typical user apps. The current link it drops you at is https://apps.google.com/user/hub
Click “Security.”
Click “Show more” option at the bottom of the security options list.
Click “Advanced Settings” to get the more options.
Select the “Manage API client access” link.
Now certain API scopes must be white-listed for the desired service account. In the “Client Name” text box provide the service account’s client ID. The client ID is obtained in the developer console. In the “One or more API scopes” add the desired scopes; comma delimited.
Note, if there are existing scopes they will be removed so be sure to re-add any that will be needed.
Enable Domain Wide API Access
Login to the Google Apps Admin Console by using the following link.
https://admin.google.com/
Go to the “Security” page.
Under “API reference” section
Make sure that “Enable API access” is enabled.
Creating an Appropriate Google Apps Service Account Key (Probably this)
Go to the Google Developer Console. Login as the Google Apps user that created the Google Apps project/service account. https://console.developers.google.com/
Navigate to the particular project with which you created the service account.
Click the "Service Account" button on the left of the project's page to bring up a page with all of the project's service accounts.
Click the vertical ellipse widget all the way to the right of the desired service account's row. Select “Create Key.”
Select .p12 key as it looks like this is what you're trying to use. Click "Create." Be sure to protect this key.
I have found that if the key is not created this way then it leaves open the possiblity for making either an API key or an OAuth 2.0 client/user key. These are the wrong types of keys to use in this case you would need to have created a service account key. The way outlined above forces you to create a service account key.
Modifying the Existing Google Apps Service Account's Settings
I'm not going over how to setup the actual service account, one thing you may need in your case is to make sure that the service account has domain wide delegation enabled. This is toggled in the Google Developer Console. Should be pretty easy to find.
Code
You do not provide your entire code base for creating the token, so just want to add a few things you might be doing improperly.
Make sure when you create the certificate that the secret you provide is the default "notasecret" string. This secret is currently the default value provided by all keys distributed by Google and is immutable during key creation. I had a link to prove this, but have since lost it.
X509Certificate2 certificate = new X509Certificate2(certificateFilePath, "notasecret", X509KeyStorageFlags.Exportable);
Just trying to advocate proper coding. While I have found some bugs in the past with Google's constant values that required additional string manipulation (adding additional slashes.) You should really be using the string constants that they provide in place of literals. I only say to use these because it provides a layer of abstraction, who is to say Google will never change the literal; unlikely.
In your case the new scope is:
GmailService.Scope.GmailModify
While the old scope was:
GmailService.Scope.GmailReadonly
Otherwise, everything code wise looks good to me.
Another thing to try would be to make sure that the actual Google Apps user account being impersonated by the service account has sufficient privileges. I would suspect a different error if this were the case, would be getting a 403 in the response instead. Anyway, in your case this is the "abc#test.domain.com" account. Once again you would go to the Google Admin Console, check its roles make sure it has sufficient roles checked for whatever it is you're trying to do. I don't know what specifically you'll need in this case, best bet would be to give it the same permissions as the "Super Admin" role then remove permissions as you go to see what it might actually need. Otherwise, if possible just give it "Super Admin."
If I was a gambler I would put my money on an inappropriately created service account key. I just recently ran into this and it was the only thing that produced the same exact error you're receiving. Other things would get me the same "Description" value in the response token, but not the same "Error" value. I'm not really even sure how the culprit key was made, because I didn't make it. I just know the fix was to recreate a new key with the steps above and that fixed the issue.