I'm trying to automate the Application Proxy configuration. I can create applications, and service principals and configure permission. But I can't find a way to configure the app proxy. I found this page https://learn.microsoft.com/en-us/graph/application-proxy-configure-api?tabs=http but it uses the beta version.
Are there any endpoints in the Graph API in the release version that I can use to configure app proxy or when is MS going to release the beta version?
As I can see the Azure portal uses the https://main.iam.ad.ext.azure.com/api API to configure the app proxy. Can I use this API in my automated process? If so, how can I obtain a token for this API?
I found that I can obtain a token using az account get-access-token --subscription $subscription --resource 74658136-14ec-4630-ad9b-26e160ff0fc6 but it doesn't work for me because I have to use oauth authorization-code-flow. Is there any chance to use this https://main.iam.ad.ext.azure.com/api API?
I found following endpoint as well but still I'm not going to pass the client username and password through my APP.
POST https://login.microsoftonline.com/{{tenatId}}/oauth2/token
resource:74658136-14ec-4630-ad9b-26e160ff0fc6
grant_type:password
username:{{username}}
password:{{password}}
Postman Request
Connected question
As mentioned in the document as the Application Proxy configuration is only supported in Beta version, you could a feature for the same for this feature to be available in the V1 release as well.
Raise a feature request here:https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/idb-p/Microsoft365DeveloperPlatform
Related
I am going to make request from postman to https://lms.freedomhighschool.ca/d2l/api/lp/1.30/users/
but after request i got message
{ Errors: [ {Message: "Forbidden"} ] }
I have Application ID and Application Key but don't understand how to use this data in my request
I highly and strongly recommend you consider switching from D2L's proprietary ID/KEY AUTH over to the Brightspace API OAuth2.
D2L has many resources available on its Brightspace Developer Community. And, even more helpful, is this GitHub repo --> https://github.com/Brightspace/Postman-Collections
In order to get access to DevCop.brightspace.com, you have to be a registered member of the Brightspace Developer Community.
Tool:
Postman (recommended for OAuth 2.0 Apps)
Notes:
Postman is a market-leading API test tool. It is available for free download at www.getpostman.com. You can find Sample Postman Environments and Collections on the Brightspace Github organization. You can find information on how to connect Postman to Brightspace in the Brightspace Developer Community.
Tool:
API Test Tool (ID Key Apps Only)
Notes:
The API Test Tool runs in a web browser and provides an interface to point to an instance of Brightspace, supply an App ID/Key pair, and log in with a given user account. Once authenticated, you can make calls using a straightforward interface. You can find more information about using the API test tool on the Brightspace Developer Community.
Conclusion use this -> API Test Tool if you have Application ID and Application Key
refer this documentation for brief info
To pass API key-value pair in header -> x-api-key
Following this quickstart guide (Python version), I was able to quickly create and deploy a Python Flask app to a project owned by my organization. However, toward the end the guide instructs "Visit your deployed container by opening the service URL in a web browser", and but this is the step I can't get to work.
Curiously, in the logs
(https://console.cloud.google.com/logs/) the 'textPayload' data element for the request is "The request was not authenticated. Either...", which seems unusual, as I'd expect an unauthenticated request to return 401, not 403. In any case, it does not list my org email address in the request, suggesting my identity for some reason isn't being supplied. Any way to fix this so I can access the URL using a user with appropriate permissions?
Note: I can access the URL by manually running "curl -H 'Authorization: Bearer <my token>'"
Cloud Run URLs aren't directly accessible if the service only allows authenticated invocations because passing the URL on your browser will not generate the credential for you. You will have to pass auth credentials on your request and the easiest way to invoke the service is to use a tool like curl which is exactly what you noted.
You have two options to authenticate your end users which are the following:
Integrate Google Sign-In.
Implement Identity Platform or Firebase Authentication.
In either of the above choices, you need a public web or mobile app that handles the sign-in flow and then makes authenticated API calls to a Cloud Run (fully managed) service.
For more information on authenticating end users, check out the official documentation.
To complement what Mr. Donnald Cucharo said, you can also use Identity Aware Proxy (IAP) to expose your application in a secure way.
This post became much longer than anticipated, TLDR: Where is my ASFS Federation Metadata located on my server? My overall task to the setup a test ADFS server in order to integrate our current application with ADFS
Hello, I'm trying to integrate our application with ADFS (it's a WPF application with a NodeJS backend), and I'm testing out Auth0 for this job (but if there are other simple solutions, I would be open to that as well - I've found no good guides so far ): espeically as a developer with no AD experience).
Regardless, I think I've set up a single server AD FS environment (locally as server1.local - with AD CS, AD DS and AD FS and that same server is the domain controller/DNS server) and set up an Auth0 relying party using this guide:
https://auth0.com/docs/connections/enterprise/adfs
In the next steps part, it says: try these quickstart guides. So I've downloaded the Angular2 quick start example project to test. But when I go to the enterprise connections and try to set up an ADFS connection, it asks for a ADFS URL
You can either provide the ADFS URL or upload the federation metadata file.
But I can't seem to find my ADFS URL. Not only that, my server is local, so it wouldn't be able to use my URL anyways right? I can just upload the metadata instead?
I've tried going to https://server1.local/federationmetadata/2007-06/federationmetadata.xml and https://127.0.0.1/FederationMetadata/2007-06/FederationMetadata.xml and https://localhost/FederationMetadata/2007-06/FederationMetadata.xml which under endpoints that's the one that shows, but ie says:
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://server1.local again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
I've enabled TLS 1.0, 1.1 and 1.2 and this still doesn't seem to give me my metadata. I've also tried that URL on Chrome and it gives a generic "This site can't be reached"
How do I get my metadata?
In the ADFS configuration, look for what you configured as your federation service name.
Use this in the URL.
https://federation service name/federationmetadata/2007-06/federationmetadata.xml
BTW the federation service name should not be the FQDN of the server.
We have created our automation framework using Appium-TestNG in which we are accessing our backend servers through RestFul Apis externally. The backend server is also based on AWS and has whitelisted the device farm IPs. When we are executing the tests locally its working fine but when we execute it on AWS Device Farm, it is giving ‘Socket Exception’ when trying to access the backend servers via our apis.
Can anyone give us a solution of how to access external Rest APIS via Device Farm?
The IP range that's in the FAQ of Device Farm point to the devices but not the device host. The device host could have a wide range of IPs but there are two ways(that I've found so far) to get around this issue in theory:
Use the private offering from Device Farm.
If you have access to the private offering for Device Farm, you're able to use the VPC integration with both the devices and the device host. So there shouldn't be any white-listing needed using this method.
Use API Gateway's private VPC integration and call this API from the tests
When using the public offering(metered and unmetered options) we should be able to take advantage of API Gateway's VPC integration. Using an private NLB in the same VPC as the REST API we can create a VPC link. The ending architecture I believe should look like this:
Then we can secure the API using an API key or custom authorizers. So then we can call this API which links to the private REST API from the device host.
Note: This might not be the best workaround depending on the use-case as then the device host will have access to the API key.
Additionally(I know you didn't ask this but wanted to link to it anyway), the easiest way I've found so far to develop REST API calls is to use Postman to make a successful call to the REST API. Then use the code snippet feature to make the same calls in the support languages from postman.
Hope that helps
-James
I have some issues trying to access google iot-core API from my remote server (hosted on Digital Ocean). The same piece of code could work on my local machine, and I ensured that even the service key was the same, yet there was no explicit message to point me in some general direction.
I'm not sure if this is an issue with the discovery API as I could get the proper response on my local machine using the curl command below but when i tried to do this on my remote server it returned a 404 error. Anyone experienced this before?
curl https://cloudiot.googleapis.com/$discovery/rest?version=v1
Google Cloud IoT API endpoint is:
https://cloudiot.googleapis.com/
The current version is v1 and it is available here:
https://cloudiot.googleapis.com/v1
The discovery doc for this API and this version is:
https://www.googleapis.com/discovery/v1/apis/cloudiot/v1/rest
You may find Google API Explorer a useful tool too:
https://developers.google.com/apis-explorer/#p/
Here is the API Explorer result for Cloud IoT API v1:
https://developers.google.com/apis-explorer/#search/cloudiot/cloudiot/v1/
Even with these endpoints, you will need to authenticate your curl requests before they succeed.
I strongly encourage you to consider using Google's SDKs (Libraries) for interaction with any Google service and for Cloud IoT for service management (munging registries, devices etc.).
Once your configuration is established, your devices should use either MQTT or HTTP.