Does Facebook allow to create anything like a Service accounts in Google Cloud Platform?
I need automated access to our FB Page via API, currently i can create User Access Token, but it is directly connected with my Personal account. I know, I can generate Page Access Token, but it still covered by my User Access Token – then I revoke it, the Page Access Token is revoked too (live example).
Is here way to create something like Service account which was not been directly connected to any User's profile?
My reason is: I want to create app to my employer which is connect to Page in non-user context (it's reading Page's events), that must still live when I leave the company
(and revoke my personal User Access Token) or when my Personal Account was disabled (for any reason).
Related
I think I might be misunderstanding how Service Accounts work in GCP, as I don't understand why (in my situation) they need to impersonate a user to complete a task.
I need to access some information that is within the Workspace Admin SDK API (for example listing chromeos devices) on my application without prompting a user to log in. I thought the best way to do this was using a service account to do this, so I could upload the details of my service account to my application, and every time I required some data it would do so via this account.
I have created my Service Account in GCP, and then given it Domain-wide Delegation with the required scopes in Google Workspace.
At first when testing this I was getting Forbidden 403 errors because I was not impersonating any user. Once I starting impersonating a user, I was able to get the data I required from the API. I also confirmed that when I removed some of the scopes on the Domain-wide Delegation, I was no longer able to retrieve that data. This means that while I was impersonating a Super Admin, I was only able to get the data for the scopes I had provided the Service Account.
This leads me to the question as to why I need to impersonate anyone in the first place?
Is this just a problem with the Directory API? In their documentation, it states that
Note: Only users with access to the Admin APIs can access the Admin SDK Directory API, therefore your service account needs to impersonate one of those users to access the Admin SDK Directory API. Additionally, the user must have logged in at least once and accepted the Google Workspace Terms of Service.
So my question is: Am I able to make calls to the Directory API as a Service Account without having to impersonate a user? If not, is it possible to make any API calls as a service account without impersonating a user, or is this just a Directory API issue?
Related to this question:
why I need to impersonate anyone in the first place?
The service account allows you to authenticate and be authorized to access data in Google APIs as documented here, by performing domain wide delegation you are granting access the service account to access your account data by impersonating a user from your domain. You can look at a service account as a way to automatize authorization as it can perform changes over several APIs not only the Admin SDK and avoid having the user impersonated to be providing access to a given API each time.
You can make calls to an API without impersonating an user but that would lead to accessing data available to the service account only as it's data belonging to their own, meaning that for example, if you make a Drive API call to create a document using a service account without impersonating it, the file could be created but it will only belong to the service account and you won't be able to access that data as an Administrator the data won't belong to your domain since the service account is different than a user account, you can check more about this in this documentation.
Now related to the last question about impersonating a user, impersonation is a way for you to make API calls on behalf of a user so that user doesn't needs to be providing API access each time that you need to perform changes, this applies to Super Admin users and regular users, this is as well noted in the documentation:
In enterprise applications you may want to programmatically access a user's data without any manual authorization on their part.
Rather than looking service accounts and impersonation as a problem, you could think about it as a way for you to make changes over your users through API without requiring them to give you access to do so. Impersonation allows you to make several changes and can help your organization to automatize several tasks when API calls are needed.
That depends on which resource/method you're using, and which privileges it requires.
For example, you can grant a service account the Groups Reader or Groups Admin admin role, and then that service account can call the methods of the groups resource. No domain-wide delegation required.
But that doesn't work for all resources/methods, and in particular it doesn't work for those that require super-admin privileges. To call these methods, you have to use domain-wide delegation to impersonate a user that has super-admin privileges.
Please correct me if otherwise. OAuth scopes defines an application's access to a user's account while custom scopes define an application's access to a resource server. After signing in, an access token is returned containing the custom scopes, which depend on the query string parameters in the Cognito domain.
Is the purpose of an app client's custom scopes to define its permission to protected resources just to ensure users are logged in from a specified app?
A User Pool can have multiple app clients, each with their own custom scopes. Why not grant all app clients access to all custom scopes? Most apps allow anyone to signup, couldn't users just login in through an app client that has a different set of custom scopes anyway? Is it a least privilege thing? Is it meant for apps that have a restricted sign up, such as paid membership? And if using a web client, the client id is exposed and there's no secret, so how does a client id prevent others from obtaining the id and posing as an app client?
How does this tie in with user specific permissions? Seems like custom scopes are only for resources that are app specific, but not user specific. Do you implement custom logic for authorizing access to specific resources, or can this also be also done with User Pools?
Also, please recommend any resources besides AWS documentation (which I've read) regarding Cognito that really help explain the use cases and entire process.
We have multiple Facebook applications and each has multiple roles (administrators, developers, testers and analytics users).
We want to export all the emails of the users with any of the above roles, but we can't find a way to do it with the developer graph API.
Can we do it with only administrator access to the applications or do we must use the Business Manager API?
You can get all users that have a role in the app via the /{app-id}/roles endpoint.
https://developers.facebook.com/docs/graph-api/reference/v6.0/app/roles
That will only give you their app-scoped user ids though.
Requesting their e-mail would have to happen separately, after you got the IDs - and will likely require that the user granted your app the email permission beforehand.
For the last few years, I've built a PHP and MySQL based website where users can submit reprographics and IT requests. I'm hoping to make this cloud-based rather than running it from a local webserver. My initial idea was to have an EC2 instance running as a web server for each company which uses my system, but as the system is PHP session based I'm assuming the security would not be great so I think I need to move towards more of an AWS system using Cognito for user management and the API Gateway with Lambda to do the job of getting the data from the databases. My question is, my current system has an admin console where the admin user can access the lists of users, and assign them permissions (session variables) which allows them access to specific pages. How would I make a webpage where users can manage the users in a Cognito user pool without giving them access to the AWS console.
Implement a Cognito AdminAddUserToGroup operation in your Lambda function for admin users to manage what Cognito Groups your users belong to. Your admins will be the only ones that are able to invoke the API call to the Lambda function because they'll be included in the Cognito Admin Group with appropriate permissions to invoke the Lambda function that you specified as the developer.
Specify permissions of what each Congito Group has access to by assigning roles for each Cognito Group.
You can also decode the jwt on the backend to determine what Cognito Group the user belongs to that made the request and use Amplify on the FrontEnd to manage the FrontEnd's display of content based on the Group (links, etc). More info about that can be found in this thread: How do I access the group for a Cognito User account?
I do not have enough points to comment on the CLI update-user-pool suggestion, but wanted you to know that wouldn't work because 1.) It would impact the entire user pool and affect ALL users in the user pool and 2.) It would make no difference in regards to what your users were able to have permission to access in your application.
I volunteer at a small local school that teaches data science and I'm trying to understand the procedure behind federated logins, but the Amazon documentation isn't helping and their forums don't seem interested.
We'd like for the students to be able to sign in to our AWS environment using either Facebook, Google, or Amazon.com, instead of manually trying to create a user for everyone who signs up.
The main thing that's unclear is how the students should sign in. Do we need to create a custom webpage using the provided javascript or .net code? We would have to contact our web developer if so. Or do we use the provided domain name? (in this case, https://weclouddata.auth.us-east-1.amazoncognito.com) This comes from the Cognito user pools though, and doesn't seem like it would apply. Besides, when I use it in conjunction with the Google client ID, I get an "invalid request" error.
You can create a custom app "Identity Broker" to create a URL that lets users sign in with Facebook/Google credentials and securely access the AWS Management Console. The broker would perform the following steps:
Verify that the user is authenticated by identity system(Facebook or Google) or use AWS Congnito.
Call the AWS Security Token Service (AWS STS) API operations to obtain temporary security credentials for the user.
Construct a URL for the console that includes the token and redirects the user to the URL on the user's behalf.
Amazon Cognito lets you to easily create customizable UI to sign in users and provides built-in federation with Facebook, Google, Login with Amazon. So you don't have worry about authentication and concentrate building your actual logic(above steps)
Here is a sample app from AWS that shows how to implement a single sign-on solution with C# and windows AD.
Python Code:
Here is the python code on how to construct the console login URL. I have used the sample python code from AWS and 'Hello world' flask app. When you hit the URL it should redirect to the console login, you can set permission using IAM role.
You can provide any login mechanism (Facebook, Google, Amazon etc) to create student account first time.
Ask user to create account using any app login (Facebook, Google, Amazon etc)
On successful login, create user in AWS using https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateUser.html API.
Add newly created user in the group https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html
You can create the user group with some specified roles and give permission (Launch EC2 Instances, Access to DynamoDB etc) accordingly.