I am attempting to follow this tutorial. My end goal is to apply device-based access levels on Identity-Aware Proxy (IAP)-secured resources, specifically App Engine. However, as the documentation states:
In the New Access Level pane, in the Conditions section, click Add attribute and then click Device Policy.
I do not see any Device Policy attribute. See screen shot below...
I believe I have properly enabled Endpoint Verification here. In Google Admin via Devices
-> Mobile and endpoints I can see device info being collected.
My Google Admin account to Google Workspace Enterprise Plus and we have Cloud Identity Premium for GCP.
Any ideas why I am unable to see the Device Policy attributes when creating a new Access Level???
Application and VM protection with device attributes needs to purchase additional paid functions BeyondCorp Enterprise
Related
I am facing the challenge to request the Bing Ads API to get a couple of metrics from it.
I am using Apache Airflow DAGs hosted on a remote Kubernetes cluster to do so. It is a nice way to automate and schedule tasks.
Now, the documentation is rather light on the point of gaining access to the API.
I have followed this https://learn.microsoft.com/en-us/advertising/guides/authentication-oauth-identity-platform?view=bingads-13#registerapplication
and the official SDK docs https://github.com/BingAds/BingAds-Python-SDK/.
I am failing at authenticating when querying, since I am lacking a couple of pieces of information.
When authenticating using the "refresh token" and "redirect URI", I do not have either. (Class OAuthWebAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L566)
When using a different method (Class OAuthDesktopMobileAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L532), I fail w/
AADSTS700016: Application with identifier '<someidentifier>' was not found in the directory '<somethingelse>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
Thank you very much in advance! If you need more details, let me know!
Also great documentation in general, if I can make it more "newb"-friendly, let me know!
Edit1:
Sadly, while there has been some traffic to this question, nobody seems to be able to answer.
I will specify the set up a bit further.
We use Airflow DAGs to request daily updates from the API. For this, we need to authenticate. The authentication comes from a "new device" every time, since the code runs on a k8s cluster which allocates the jobs dynamically to it's pods.
For authentication, we ventured into different solutions, but all require some form of human interaction to get the refresh token into the DAG.
Is there any solution which allows for a hands-free deamon like many-server-to-server communication?
This link sheds some light on what we are looking for: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration#api-permissions---app-permissions-and-admin-consent
Sadly, the Bing Ads API does not show up there.
What key piece of information are we missing?
Bing Ads, like Google Ads, uses OAuth for its API.
If you reference the Getting Started page, it mentions that you need a developer token, complete with links.
You can follow these steps to get a developer token for production.
Sign in with Super Admin credentials at the Microsoft Advertising Developer Portal account tab.
Choose the user that you want associated with the developer token. Typically an application only needs one universal token regardless how many users will be supported.
Click on the Request Token button.
Regarding your specific scenario--an application running in the cloud without an interface--you should know that OAuth requires you to interact with it to set things up. So run your app locally ONCE, or at least the getting_started code from your language's walkthrough: https://learn.microsoft.com/en-us/advertising/guides/walkthrough-desktop-application-python?view=bingads-13
Running it locally will go through the authentication process with your browser and generate a refresh token (in the file refresh.txt by default). Store this file with your code. It will have to be on the server that's making the request, and since it's in Kubernetes, you'll have to keep it with your container file.
WE have our REST services deployed using bluemix container groups. Can some one tell me how to configure access to these APIs through Bluemix API Connect? I Created product, catalog. Also imported my swagger in catalog. I can see the APIs listed. but not able to access them. Can someone guide?
Since you've already created a product, I'll assume that you've already added your API(s) to that product. If not, do that now.
Once you've done that, look for the Stage menu (the little "Cloud with an up arrow" icon) in the upper-right-hand corner of the product detail page. From the corresponding menu, select the catalog you want to stage the product to.
After that completes successfully, navigate to the API Connect dashboard and click on the catalog to which you just staged the product. At this point, you should see the product and its status will be listed as "Staged."
Click the overflow menu (three dots) on the right-hand side of the product row and select "Publish" from the resulting menu. You can likely accept any default visibility settings. Once that operation completes, the API will now be accessible via the catalog's gateway URL + API base path. (You can find this in the Catalog settings -> Endpoint panel.)
For more information on publishing APIs, see this documentation: https://console.bluemix.net/docs/services/apiconnect/apic_006.html#apic_010
Or if you want to use the CLI: https://www.ibm.com/support/knowledgecenter/en/SSFS6T/com.ibm.apic.toolkit.doc/capim-toolkit-cli-publish-apis.html#concept_nll_3ry_xv__publish_apis
on Bluemix to call your api , you need to "publish" your product to a portal. First of all prepare your Portal:
Go to Dashboard -- > Your Catalog -- > Settings -- > Enable Portal and select Portal-Delegated-User-Registry.
After some time , you will be accessing your portal . Subscribe new user through that portal. Portal GUI is very helpful. You will be able to learn by yourself how to call your API.
Good luck!
We're trying to sign-up new users to our App - using either Facebook or Email/Password. (A very typical situation )
Facebook Auth is easy & Built in.
Auth by Email/Pass - now seems to be not supported (See Below)
https://azure.microsoft.com/en-us/documentation/articles/app-service-authentication-overview/
How is this done?
I see Azure Active Directory Auth is Built-in ...Is MS suggesting we use Active Directory for Email/Pass Sign-ups?
Thanks
In the link that you referenced, there is a section titled "Do-it-yourself authentication" with links to starting points for rolling your custom authentication. So Email/Pass authentication is STILL supported.
What is not supported is side-by-side custom authentication and using the gateway authentication that you get with Facebook/Azure AD/Google/etc.
So yes... if you want to use the gateway authentication... use Azure AD. If you want to roll your own, you own it all. If you choose to roll your own, you can still use the FB/Google/OAuth, but you will be coding and configuring on your own, not in the portal identity setup.
I have a developer account and have created an application in development mode, just for testing purposes. I have also created a business manager at business.facebook.com, and added my test app to it. I have an ad account as well, which is added into the business manager. I also added the ad account ID to my application under the Advanced --> Advertising Accounts --> Authorized accounts.
However, when I use the Facebook Graph API Explorer, and set it to use the application I created, then make a call to /v2.3/[BUSINESS_ID]/product_catalogs, I get the following error:
"message": "(#275) Ad account cannot be determined for this request",
If I call the ad account directly, at /v2.3/act_[adaccountId], i can see the ad account information just fine.
If I create a product catalog myself in business manager, then call the endpoint for details on that product catalog at /v2.3/[product_catalog_id], i get the following:
"message": "(#200) The app is not whitelisted to use this API",
If i am accessing catalogs that i am the admin for, and for apps that i am the admin for, and am using development access, why would it need to be whitelisted?
The issue here is as you said, your application is in the Development Tier for the Ads API. There are 3 tiers to the Ads API:
Development Tier
Basic Tier
Standard Tier
All of which are documented in the Marketing API Access Levels documentation. In order to access any part of the Business Manager API your application will need to have access to the Standard Tier.
I would recommend that you follow the steps in the documentation to move up the levels and when you believe you are ready, you can apply for Standard Tier Access
I am making a .NET application that will allow potential users to upload invoices they make on my app to their quickbooks account that they have set up and synchronized with their QBD version.
what steps will they/I need to take so that when they use my app, it will upload invoices to their account? Is it:
a) when they set up their account with the Intuit AppCenter, they will pick my app from the app center services (in doing so, it will generate a set of oAuth connection parameters for me to put into my app to push invoices to their account, if so how will I get these)?
b) Will I set up an account via the Intuit Platform Partners, and ask the user to use my account ID and Password by which they will "create new app" under my account for the purposes of generating oAuth connection information for my app to use?
c) Something different from the a) and b)?
Thanks!
The OAuth stuff is specifically designed to allow end-users to push a set of OAuth tokens/credentials from QuickBooks to your app. You then store the OAuth tokens, and use those to communicate with QuickBooks.
This is an accurate description of what happens, yes:
a) when they set up their account with the Intuit AppCenter, they will
pick my app from the app center services (in doing so, it will
generate a set of oAuth connection parameters for me to put into my
app to push invoices to their account, ...
You can read more about that process in the docs:
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0011_from_the_intuit_app_center
The other scenario is that, if you allow it, the user may choose to connect to QuickBooks from within your app. In this case, they'll click the "Connect to QuickBooks" button (see the docs here: https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app) which forwards them to Intuit's site, generates the OAuth tokens, and then sends them back to your site with the OAuth tokens.
In either case, the OAuth tokens will be sent to you so that you can store them and use them to communicate with the QuickBooks APIs.
This:
... and ask
the user to use my account ID and Password by which they will "create
new app" under my account for the purposes of generating oAuth
connection information for my app to use?
Is absolutely not what you want them to do. The whole point of OAuth is that you don't need to share any usernames/passwords of any time with any one.
Here are some additional answers to your other comments:
The part I am trying to figure out is what my customers will need to
do to be able to benefit from my app and its QuickBooks Integration
functionality.
They will need to log in to their Intuit.com account, and follow the prompts to connect their QuickBooks company to your app (i.e. follow the prompts to forward the OAuth credentials to your app).
Sounds like he/she will need to set up some account with ID and
password.
If they don't already have an Intuit.com account, they will be prompted to create one during the OAuth process. In the case of QuickBooks Online, they will ALWAYS already have an Intuit.com account (it's the same thing they use to log in to QuickBooks Online).
Now it seems to me that there are two ways that the customer can set
up accounts with Intuit.
They can set up an account through AppCenter, or within QuickBooks desktop directly (when you install the software, it prompts you) or if you're using any Intuit service already (e.g. QuickBooks Online) then you use your existing QuickBooks Online account.
Developer.Intuit.com accounts are only for developers (e.g. for YOU). Your end-users will not have a developer.intuit.com account. Nor do they need one.
a) what are the differences between the two?
Developer.Intuit.com accounts are only for developers. Your end-user will never see the developer.intuit.com website, nor will they see the option to "Create an App".
b) which should be used if the customer wants to set up syncing their
QBD? c)Which should be used if the customer wants to use my .net App.
d)Which should the customer use if they want both (b) and (c)? e) If
the customer creates an account the 2nd way, won't they get confused
by all the "developer" lingo?
None of those questions are applicable - end-users will never see or be prompted about any of the developer stuff. The only reason you see that is because you're registered as a developer. Normal end-users will not be, and thus won't have any of these options.
f)What if the customer has already synced their QBD with intuit?
Then they can just log in to their existing account to get connected (i.e. to send the OAuth credentials over to your app).
With regards to your questions:
A developer can choose to get his app listed on the appcenter or not depending on mkting requirements.
To understand the difference in the process- you can create a sample and then on developer.intuit.com, go to My Apps-> manage my app-> select your app. Then test connections.
You can use any of the above to use QBD data. Please see the additional info too that I have provided.
Also go through the link which consolibyte has mentioned.
If you are logging in from appcenter app, then since you are already logged in, then only OAUTH will be required.
In logging from within your app, you do not need to provide your user Id and password. The user needs to register for the first time with Intuit.com and then OAUTH process follows for him. These open id/email details can be saved in your db so that user need to enter them a next time.
The customer is never about the details of the developer except for the app which will access their company data.
The sync manager for QBD
OAUTH authorizes your app to connect to their company files.
Any of the above can be used to access QBD data.
The sync manager runs manually or automatically. So, customer can choose to sync/not sync his data.
---------------Addtional info----------
There are two ways to integrate with QuickBooks, the first is with REST APIs and the second is with the downloadable QBXML SDK v12. The REST APIs and that integration model is for applications that are to be sold to customers via our Appcenter. They are generally Saas applications.
The second model is the QBXML sdk which is available for anyone to use, especially for custom integrations.
The reference for the QBXML SDK is here
http://member.developer.intuit.com/qbSDK-current/Common/newOSR/index.html
Please go through:
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits ->QBXML SDK
Lastly through the QBXML SDK you can add a custom field to any entity you want. See the reference above and take a look at DataExt Add Request. and once added Query Request. I believe this will give you what you are looking for.
Keep in mind this is for QuickBooks for Windows not QuickBooks Online.
You can go through FAQ page too-
https://developer.intuit.com/docs/0025_quickbooksapi/0058_faq
I am settled at this point from what Consolibyte has shared and what I have learned also. The whole picture (for me at least) is that both the Developer Account AND the App Center Account is needed. The Developer account provides the consumer key, consumer secret and application token that the .Net app will use to authenticate with Intuit. The App Center Account is needed to allow the user to sync their QuickBooks Desktop data to a location where the app center (and other 3rd party apps) can have access to it (after user authorizes of course), and to give it's user an ID and Password needed to authorize the .net app ( or any app for that matter) to access his/her Intuit data. It is the combination of the Developer Account's tokens and the App center Account's ID and password that allow the generation of an authentication/access token by which the .Net app can instantiate a Dataservices object so it can read/write to the user's instance of QB data in the App Center. Apart from the user creating an account in the App Center and synching their QB Desktop data with it, There should be little or nothing else to do except provide the ID and password, providing the .Net app is coded right. I am not talking about OpenID in this case, but do know that it uses the same ID and password.
...so I'm good. Thx.