Looking over the possible connection provider in Azure Portal, I've determined that my use case requires the the "OAuth 2 Generic Provider" (rather than the "Generic OAuth 2" provider). However, I can't seem to find any documentation on how the templating should work or what variables are passed to the template.
I'm attempting to setup a connection with Azure DevOps. First I tried using the "Generic OAuth 2" provider and the test flow works up until the botframework's token service receives the authorization code from Azure DevOps. It'll redirect me to a "Bad Request" page. I can take the authorization code from the redirected url and construct the token call as Azure DevOps' documentation describes and it works correctly so I'm guessing this is an issue with how the botframework's token service is calling Azure DevOps hence why I need to use the "OAuth 2 Generic Provider" since it allows me to specify how the token service calls Azure DevOps.
Ideally, this would be added to the documentation somewhere or - even better - as hints on the Azure portal page.
Edit: Added a screenshot of the page. What do you put in the "Template" fields on that form?
I got a hold of the team behind that form. Commenting here for anyone that searches for something similar on Google.
These are the values that worked for me, you'll need to set your own id/secrets/scopes
Scope List Delimiter: ,
Authorization URL Template: https://app.vssps.visualstudio.com/oauth2/authorize
Authorization URL Query String Template: ?client_id={ClientId}&response_type=Assertion&state={State}&scope={Scopes}&redirect_uri={RedirectUrl}
Token URL Template: https://app.vssps.visualstudio.com/oauth2/token
Token URL Query String Template: ?
Token Body Template: client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={ClientSecret}&grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion={Code}&redirect_uri={RedirectUrl}
Refresh URL Template: https://app.vssps.visualstudio.com/oauth2/token
Refresh URL Query String Template: ?
Refresh Body Template: client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer&client_assertion={ClientSecret}&grant_type=refresh_token&assertion={RefreshToken}&redirect_uri={RedirectUrl}
Related
I'm in the process of migrating from Cloud Service (classic) to Cloud Service (extended support) in Azure. Unfortunately, CS extended support documentation is very scarce and often inaccurate, so the process if very much not straight forward. At this point, I'm working on the deployment pipelines. With CS classic, we used management APIs to deploy/update/etc. The API for extended support is more straight forward, however, again, the documentation is lacking. The best I found was this page: Cloud Service - create or update. While this provides fairly good starting points, I'm struggling to find any info on the following points:
ServiceConfiguration element - what format is this in? Is it pure XML (encoded within JSON, of course) or something else? For classic API, service configuration was passed as a BASE64 encoded XML.
The request body (JSON) contains some of the same elements as in the service configuration - what happens if they don't match?
Package URL - what format is this in? The package is stored in an azure storage account - so how do I reference it? Also, for authentication, I can't grant the CS any permissions to the storage account, as it's not created yet (it doesn't exist!) - but it seemingly needs this permission in order to be created.
RDP extension - what format is "password" in? Is this really just a plain password? For classic, RDP password was encrypted using a certificate, which was separately uploaded into the service.
SSL certificate from the vault - how is authentication going to work? Again, the CS doesn't exist yet, so I can't grant it any permissions in the vault.
On authentication front, I managed to send the auth request and get the oauth2 token, which I would then use for this API - could this be enough? Of course, I can try this, but need to understand the other things first (i.e. format of some elements).
Note separately that deployment pipeline is executed from Jenkins and must stay that way - I don't have any control over that.
UPDATE: I tested this as best I could with service configuration being plain xml, with content matching the rest of json input, plain text password for RDP extension, and hoping for the auth to use bearer token. The response I received was 400, with the following details:
{
"error": {
"code": "InvalidParameter",
"message": "The value of parameter packageUrl is invalid."
}
}
So, back to my point 3 above - what is the format of package url?
UPDATE 2: After some experimenting, it did accept the package URL with the SAS token. Now I'm stuck with this error:
{
"error": {
"code": "StandardPublicIPAddressNotSupportedCloudService",
"message": "Standard public IP not supported for cloud services."
}
}
Web search for that string returns 0 matches. The template I'm using is copy/paste from MS documentation; the process I'm using is exactly per MS documentation. Any further help massively appreciated.
This isn't exactly what you're after, but I used the following article to help with generating a template.json and parameter.json file which then could be used through Powershell.
https://techcommunity.microsoft.com/t5/azure-paas-blog/how-to-use-azure-devops-to-publish-cloud-service-extended/ba-p/3675180
This is what my Powershell script eventually looked like:
New-AzResourceGroupDeployment -ResourceGroupName "cses-rg" -TemplateFile DeployArm.template.json -TemplateParameterFile DeployArm.parameter.json -packageSasUri $cspkg -configurationSasUri $cscfg -cloudServiceName cldcsestest -deploymentLabel myDeploymentLabel -publicIPName 'MyPublicReservedIp' -rdpPassword $rdpPassword
I only used the Powershell script locally for quicker testing, but my goal was to get it working with Azure Dev Ops.
I have a React SPA which uses msal. I have configured Azure AD as Identity Provider for my AADB2C. I can signIn/signOut and other operations.
If my user signs out off my application, I want to also sign out of my Identity Provider. I looked a bit into this matter 1, 2, 3, 4, 5.
At this moment, I use msal's logoutRedirect method.
const url = new URL(AadEndSessionEndpoint);
url.searchParams.append('post_logout_redirect_uri', SPAUrl);
instance.logoutRedirect({
postLogoutRedirectUri: url.toString()
});
What happens, after my user signs out of my AADB2C, he gets redirected to the AAD end_session_endpoint. I can sign out there as well, but my user gets stuck there. Even though I'm passing the post_logout_redirect_uri query parameter to go back to my app, it ignores it.
How could I make this work?
You are doing an RP Initiated Logout in OpenID Connect terms, meaning you need to also send the id_token_hint query parameter.
I can also confirm that sending both query string parameters logs out successfully for my Azure developer account:
url.searchParams.append('post_logout_redirect_uri', SPAUrl);
url.searchParams.append('id_token_hint', myIdToken);
I think the MSAL library requires you to use getAccount instead:
const account = msalInstance.getAccount();
await msalInstance.logoutRedirect({
account,
postLogoutRedirectUri: "https://contoso.com/loggedOut"
});
UPDATE
Your code above is not right - the post logout redirect URI should be that of your own app - I expect the library already knows the end session endpoint location - so just do this:
instance.logoutRedirect({
postLogoutRedirectUri: SPAUrl
});
At the same time it is worth being aware that the full standards based GET URL should look like this. With the knowledge of the expected URL you can check that you are sending the right request via browser tools:
https://[AadEndSessionEndpoint]?id_token_hint=[myIdToken]&post_logout_redirect_uri=[SPAUrl]
The end session endpoint should be a value such as this by the way:
https://login.microsoftonline.com/7f071fbc-8bf2-4e61-bb48-dabd8e2f5b5a/oauth2/v2.0/logout
I am attempting to access the SharePoint Online REST API (this is hand coded REST calls, no library being used).
Access tokens are acquired using authorization grant flow as follows:
I send the browser https://login.microsoftonline.com/common/oauth2/authorize?...
This redirects to a handler endpoint that we extract the access code from
I obtain the tenant ID by:
GET https://{tenantname}.sharepoint.com/_vti_bin/client.svc
Then extracting the tenant ID from the WWW-Authenticate header
I then POST https://login.microsoftonline.com/{tenantid}/oauth2/authorize to obtain the access token
When I use that access token, I am able to do queries using:
GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=....
This works and returns documents.
But when I attempt to retrieve information about one of those documents:
GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I get a 404 response with the following body:
{"odata.error":{"code":"-2130575338, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"The file /TestFiles/test.pdf does not exist."}}}
If I navigate to the URL in a browser (https://{tenantname}.sharepoint.com/TestFiles/test.pdf), it accesses the file without issue.
This makes me think that I'm running into some sort of permission issue.
I have tried setting the following scopes in the authorize redirect:
Attempt 1: scope = Web.Write AllSites.Write Site.Write
Attempt 2: scope = https://{tenantname}.sharepoint.com/.default
Attempt 3: scope = https://{tenantname}.sharepoint.com/Web.Write https://{tenantname}.sharepoint.com/AllSites.Write https://{tenantname}.sharepoint.com/Site.Write
No matter what I set as the scope parameter of the authorize URL, the JWT details of the access token show (I can post the entire decoded JWT if anyone needs it):
"scp": "User.Read"
Nothing I do has any impact on the scp in the token - I have no idea if that's the issue or not. If it is, I would appreciate hearing how to properly request scope.
The application registration in Azure Active Directory has desired permissions (plus more):
What am I doing wrong?
UPDATE: Switching to OAuth endpoint v2.0:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
With query parameters:
response_type = code
client_id = my app id
redirect_uri = my redirect uri
scope = <varying - I'll explain what happens under different scenarios below>
Here's what I've tried for scopes:
AllSites.Write Site.Write - the redirect has invalid_client with error_description = AADSTS650053: The application '' asked for scope 'AllSites.Write' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/AllSites.Write https://.sharepoint.com/Site.Write - the redirect has invalid_client with error description = AADSTS650053: The application '' asked for scope 'Site.Write' that doesn't exist on the resource '00000003-0000-0ff1-ce00-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/.default - this goes through
But the resulting JWT has only scp=User.Read
The following works: GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=
But the following returns a 404: GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I don't understand how Scope=.Default isn't including the allowed permissions from the application registration. And I definitely don't understand why the AllSites.Write scope is failing when it's explicitly specified.
If it helps, I have also tried all of the above using a tenant specific authorize endpoint instead of 'common':
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize
UPDATE2: More scope changes:
I finally found a magical combination that works:
Use a tenant based URI for the /authorize and /token endpoint and use {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following:
"scp": "AllSites.Write User.Read"
I am completely perplexed about why Site.Write wasn't allowed. I suppose that AllSites.Write is a superset of Site.Write, so maybe not needed?
All of my testing so far has been on my own tenant, next step is to test on a different tenant and make sure it actually works there as well.
It seems you use v1.0 endpoint https://login.microsoftonline.com/common/oauth2/authorize but not v2.0 endpoint https://login.microsoftonline.com/common/oauth2/v2.0/authorize. If we use v1.0 endpoint, we should use resource instead of scope. So that is why the scp claim in your access token always the same no matter you modify the scope.
You should use resource with https://{tenant-name}.sharepoint.com and the parameter scope is useless when you use v1.0 endpoint.
If you still want to use scope parameter, you can also change the endpoint to v2.0. Just add v2.0 into your endpoint, like: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
I finally found a magical combination that works:
use the https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize and https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/token endpoints
specify {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope - that was the primary problem):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following: "scp": "AllSites.Write User.Read"
This works across tenants and gets us the access we need.
For thoroughness, we also specify offline_access scope so we get a refresh_token in addition to the access_token.
I have a Logic App with an HTTP initial trigger that is all set up:
When I make the POST to the URL that is given to me (looks like https://___.azure.com/workflows/___/triggers/manual/paths/invoke?____), I get back:
{"error": {
"code":"AuthorizationFailed",
"message":"The authentication credentials are not valid."
}}
For this case, I need to accept anonymous calls.
Where in the Azure Portal do I setup the permissions for this?
The closest I've found is the "Access Control Configuration", and it is set like this:
Logic Apps does not allow anonymous calls, you are required to provide the SAS key, which is provided in Url generated on the request card.
Found the issue. My client-side code was appending a parameter to the URL without realizing the URL already had query parameters. As such, it was adding to the last parameter rather than adding a new parameter. With that fixed, the call works.
Yes, the URL that will be present at the callbacK URL while creating should work, Does your URL has SP, sv and sig query paramemters?
I have an ARM template that creates, among other resources, a web site that hosts a webjob and a job that is part of a scheduler. I have managed to get everything configured through the ARM template except for the authentication.
When the job needs to run, it creates an HTTP request that should kick off the webjob. Unfortunately, the webjob is never started. If I go into the Azure portal and update the settings for the job (Action settings) and configure Basic authentication (with the deployment credentials) everything starts working as expected, but I'm not sure how I can retrieve those credentials from the ARM template. I could run it once, create the web site, get the credentials then update the ARM template, but that defeats the whole reason I'm building the ARM template in the first place.
I found an answer that got me most of the way there; you can set the Uri of the request to list(resourceId('Microsoft.Web/sites/config', variables('webSiteName'), 'publishingcredentials'), '2016-08-01').properties.scmUri. You will also need to concatinate the rest of the path (e.g. /api/triggeredwebjobs/{webjobname}/run)
The Uri produced by the above code includes the basic auth credentials, and that is parsed at some point and the username and password are taken out of the Uri so they aren't visible in the Azure portal and the authentication is set to 'Basic', and the credentials are set to the extracted values.
However, my Uri had query string appended to the end to pass parameters into the webjob. During the deployment process, the query string gets mangled (the question mark is escaped to %3F and if you have any escaped characters in your arguments value, they will get unescaped.
I managed to work around this by concatinating strings together to make up the Uri (NOT using the scmUri property), and then setting the authentication property, which is a sibling to the uri property to look like the following
"authentication": {
"type": "Basic",
"username": "[list(resourceId('Microsoft.Web/sites/config', variables('webSiteName'), 'publishingcredentials'), '2016-08-01').properties.publishingUserName]",
"password": "[list(resourceId('Microsoft.Web/sites/config', variables('webSiteName'), 'publishingcredentials'), '2016-08-01').properties.publishingPassword]"
}