Auto Assign Space and Org to new CF Users - cloud-foundry

we have a cloud foundry demo installation for customers. Customers are able to create an account. Now, I would like t assign automatically a specific org and space incl. roles to every new user.
Is that possible?

You could create a web application that users go to create their account then use uaa apis and cloud controller apis to create and assign the user to whatever you want. This application can use uaa client accounts with appropriate authorities.
If you only want users to create their accounts using your application I believe you can tell uaa to disable self service links in the uaa ui using "login.self_service_links_enabled=false" and can probably stop people from creating their own accounts on the CLI by removing the "scim.write" scope from the cf client.

There's nothing out of the box that does this. I can't see anything in the events API that you could plug into either.

Related

Google Cloud Project Service Accounts

I am using a Google Cloud Project to automate the creation of some users inside of our organization. I have been using some API's that are hosted using the Google Cloud and have had no problem authenticating and using the API's, however I am not sure if I should be using a service account for this. I am currently using the Google Drive API, the Google Admin SDK(Directory API), the Sheets API, and the Docs API to create some accounts and manage an error log.
What I am asking is, should I be creating a service account to use the API's or is my own personal Google Workspace account okay for creating these? Is there a site/video/something that can guide me in the right direction if I do need to create a service account. I personally would rather have all of the automation using a service account for authentication, but the only videos and tutorials I found on using the service accounts are trying to use resources pertaining to Cloud Computing and service accounts that are impersonating other service accounts.
Using a Service Account is the best course of action for security reasons when you are the one giving authorization and authentication to your organization.
It is identical to granting access to any other identity to allow a service account access to a resource. For instance, suppose you only want an application that runs on Compute Engine to be able to generate items in Cloud Storage.
As a result, instead of managing each and every one of your users, you may limit and manage service accounts, assign certain roles to specific users or groups, and keep track of them because several service accounts can be created in a project.
Since you use Google Workspaces, I also advise you to read the shared documentation posted in the comments by #John Hanley.

Google Workspace: manage domain-wide delegation programmatically

I have an application that can manage Google Calendar within the Google Workspace of the company. The application contains more than one company.
I want to use domain-wide delegation. As described here or here admin of the workspace needs to add service account id and scope manually.
Is the way to do this programmatically?
After some research and also looking into Google Workspace's Admin SDK documentation here and here this does not seem to be an available option at the moment.
You may want to submit a feature request here for that.
For service or local applications, the admin has to manually generate the service account and grant this service account with domain-wide authorization. There is no way to do this programmatically (unless for pure SaaS applications).

How to create Organization and space in mindsphere using cloudfoundry?

When I am using the following code:
cf create-org (ORG_name)
I am getting an error:
You are not authorized to perform the requested action
In many distributions of Cloud Foundry, an org represents an entire company or account so you likely won't be able to create another org without signing up for another account. (See MindSphere documentation)
Orgs and spaces are used to control user permissions and organize resources such as apps and services. Unless you are trying to create a space that you don't want your org manager to see, you might just create a new space instead.
Actually I have used to push my application to mindsphere, but it was not done because i used normal user account. It need developer account to push the account.
If this is a Developer tenant, then you will already have an org for the tenant, which has the same name as the tenant. You can't create another org. By default, only the tenant owner is in the OrgManager role which can access the org.
Either:
Get the tenant owner to add you to the OrgManager role
Use MindSphere Settings to create Service Credentials for Cloud Foundry. This will allow you to login to cf using those credentials, access the cf org and add your real user to the org

Create New Service account programmatically

Is there an Google Admin API to create a new service account using the credentials of another service account?
I'm creating a SAAS solution where I'm providing certain services to end users from different domains. Google recommends (not restricts) to use different service account (ESA) for each domain so that their data is entirely segregated.
To achieve this, I need to create a new ESA programmatically whenever a new customer signsup.
I'm able to provide the services to all users (from different domains) using single ESA, but I was not able to find any API that allows me to create a new ESA programmatically. Is it possible?

Dummy account in Google Developer Console?

After we created a new project in Google developer console, we see one App Engine service account and one Google APIs service account already there in "Permission" page. But we have no client Ids in credential. Those two accounts seems to be dummy, what are they for?
They are not exactly dummy.
Those are "service" accounts meant to be used if you want an application or utility/tool that is sitting inside/on your app engine VM or compute engine VM, to perform actions that will require authentication ... having service accounts should ideally let you can skip the oauth step which would otherwise require browser access and user intervention ... things that an automated process in a VM should not have to deal with.
I'm guessing they were provisioned automatically with ease of use (? shrug) in mind so folks wouldn't have to go about creating them.
https://cloud.google.com/compute/docs/faq#serviceaccounts
https://cloud.google.com/compute/docs/authentication