I see there is a REST API for blocking placements at a customer level.
But I cannot find if there is an API (preferably REST) for blocking at an ad-group level.
Is it only possible to remove an existing placement, but not blocking for the future as well (like possible at an account level)?
Blocking at an account level ("NegativeCriteria"):
https://developers.google.com/google-ads/api/rest/reference/rest/v10/customers.customerNegativeCriteria/mutate
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
I've been integrating Firebase for a clients back-end dashboard system and I'm generating timestamps on activities which for FINRA/SEC purposes they would like to see set immutable.
Users have zero control over the data, all of it is handled by API calls to Node but through Node, the server is given full access permissions. Does Firebase provide a way to create a collection so that not even Node nor the Web UI can make changes to the info? Similar in the way an S3 vault-lock works.
I have a microservice architecture, where one Single Page Application accesses three different APIs:
I am securing those APIs via the Microsoft Identity Platform and therefore I also need service principals.
My first approach matches with all the examples I found on blogs or in the MS docs.
In this case I have one app registration for the client app and three additional ones for the APIs:
This has the following impact:
Each API has its own audience.
I get four service principals for each application.
I get three different places where I have to administrate the user assignments to roles. (for example: User A can read assets from API A etc...)
This works, but comes also with some problems:
The other admins that are managing which user is allowed to do what are confused about three different places they have to assign roles. It would be nicer to have one central place.
The roles of the users are not placed in the ID tokens, because only roles of the client application would go there... but I do not want to assign permissions in the client app again.
If API A wants to call API B or C, I need two access tokens for other APIs.
This lead me to a second idea:
Here I have one registration for all 3 APIs. This already solves problem 1 and problem 2. But it also gives me a strange feeling, because I never found other people doing so.
Also my ID tokens are not telling me the roles, so to fix this, I could even go another step further to a single app registration for everything:
Now one registration exposes an API and consumes this API also. Something what is possible and seems to solve my problems. I even get all roles for the users in my ID tokens AND in my access tokens now.
However, this is contradictive to all other examples I found.
Which disadvantages does the last solution have?
Which of the three approaches should I chose?
Which disadvantages does the last solution have?
One thing that comes to my mind is that you want API A to be able to edit data in e.g. MS Graph API, so you give it the app permission to Read/Write Directory data.
Now with the shared app registration this permission has also been given to API B and API C.
So the principle of least privilege may be violated in the second and third options.
But it does make it easier to manage those APIs as you noticed.
The third option does open up the door for the user to acquire access tokens to any APIs that you might want to call on behalf of the current user from your APIs.
So if you wanted to API A to edit a user through MS Graph API on behalf of the user, you'd have to require the read/write users delegated permission (scope) for your app.
This would allow the user to acquire this token from your front-end as well, even though that is not intended.
Now they would not be able to do anything they wouldn't otherwise be able to do since the token's permissions are limited based on the user's permissions, so this might not be a significant disadvantage.
Which of the three approaches should I chose?
As with many things, it depends :)
If you want absolute least privilege for your services, option 1.
If you want easier management, I'd go with option 3 instead of 2.
There was that one thing I mentioned above about option 3 but that does not allow privilege escalation.
I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
Service or daemon authentication to the Microsoft Graph grants access to a limited number of functions.
For example, to be able to work with Planner and tasks, you have to be logged in as a user. In other case, we can't access most of user details, we can't access user's files and so on.
Why service or daemon must have more permissions then now? In our case, service should automatically create Planner tasks and Calendar events for specific users or groups according to automatically registered events. Sometimes it should also create or add or read files in OneDrive of this user. Also automatically, of course. Due to Microsoft Graph restrictions, it is easier to use additional 3rd-party service to track tasks, or even write our own. The same situation with files.
Microsoft Graph looks like a powerful API, but due to its access restrictions it becames unusable when you need to made something automatically, without any user actions.
What is the reason for most of these restrictions?
Is there any walkarounds?
Office 365 works perfect with deamon applications but not in your usecase. It works great for modifying a user' calendar for instance. See here https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0&tabs=cs
Apart from that, if you want to have something changed in the graph api. The best way to let Microsoft know is to create an item on UserVoice. This is to let users influence what features they need, maybe you can express your wishes there. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests