How to give access for IBM Cloud for Domain Name Services and Cloud Internet Services to account users? - authorization

How to give access to my team mate on IBM Cloud account on the resources, Domain Registration Service and Internet Services resource?
The admin wants add privileges. But when he looks the list, can not find the Domain Registration and internet services. The users are already in the IBM Cloud account.

There are a couple of ways to accomplish that with IBM Cloud IAM (Identity and Access Management), including granting the permissions directly to the users in questions or creating an access group with the privileges first and adding the users to that group (best practice).
DNS Services has the listed roles including Administrator
Cloud Internet Services has a Manager service role
So your admin would
create an access group
add the privileges for DNS Services and CIS to it as policies
would need to make sure that privileges on the resource group to see the service instances are added
add the users to the access group.
Thereafter, you should have access.

Related

How to configure Auth0 to authenticate with other companies Azure Active Directory?

I have Auth0 configured with Social Connections > Microsoft Account.
This is linked through Client ID/secret to a Microsoft Azure Active Directory tenant in my Microsoft organisation, with an App Registration set to allow:
Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
All users with a work or school, or personal Microsoft account can use your application or API. This includes Office 365 subscribers.
When I log in through my app, I can authenticate successfully using my personal account eg. blah.blah#gmail.com
However, when I try to authenticate with my work account blah.blah#myawesomecompany.ai, which is managed with an Azure Active Directory, it fails with
"That Microsoft account doesn’t exist. Enter a different account or get a new one.":
I thought given the Microsoft settings it would allow it connect.
How can I make Auth0 allow Microsoft authentication with other company's existing Azure Active Directory?
Also - can I configure it to limit that feature to specific companies AAD eg. those I have specifically nominated?
Is there a way to configure this without having to upgrade to Auth0 Enterprise?
I tried to reproduce the same in my environment and got the results like below:
I created an Azure AD Application:
Note that: Make sure to use common endpoint for Multi-Tenant and Microsoft accounts.
For sample I used the below endpoint to authorize the users:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=ClientID
&response_type=code
&redirect_uri=RedirectURI
&response_mode=query
&scope=https://graph.microsoft.com/.default
&state=12345
When I tried to sign-in with the personal account, the user logged in successfully like below:
And now I tried to login with other tenant user like below:
By using common endpoint, I am able to sign with personal accounts and other tenant accounts too successfully.
To limit the feature to specific companies AAD, check this blog.
Auth0 Enterprise is required to authorize tenants to the Azure AD Application.
For more in detail, refer below MsDocs:
Use tenant restrictions to manage access to SaaS apps - Microsoft Entra
Multi-tenant application with a whitelist on tenants authorized by Marshaljs
Assuming you want to use multi-tenant app to allow users from different company to sign in your application with their work account. Let's assume you create an Azure AD application in your tenant(tenantA).
Then in your app, you may set the TenantId as the tenant id so that even you created a multi-tenant app, you will only allow users in your tenant to sign in. And the sign in request may look like https://login.microsoftonline.com/{tenantA_tenant_id}/oauth2/v2.0/authorize?, with this link, you will be able to use account like user#tenantA.onmicrosoft.com to sign in, you can also use personal account which is invites to tenantA as a guest to sign in your account.
If you want users in tenantB to sign in your app with account like user#tenantB.onmicrosoft.com, then you must set the TenantId in your app as common which will make the auth request look like https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
Then when sign in the application created by tenantA with account in tenantB, you may see screenshot below. After consenting it, user#tenantB.onmicrosoft.com can sign in this application.

Accessing a Postgres SQL Server from a Google cloud (gcp) account using another Google cloud (gcp) account which has a virtual machine

I have a Postgres SQL Server in my Google cloud account (account a). I can access it using the external IP address locally or using the internal IP address from one of my virtual machines.
I have a friend who has another google cloud account (account b). He can't access the account unless I white list his VM's ip address. Is there another way he can access my SQL Server such as adding or changing the IAM permissions?
You can use Cloud SQL IAM database authentication. Note that this feature is on Pre-GA and it is only available for Cloud SQL with PostgreSQL but basically Cloud SQL is integrated with IAM to help you better monitor and manage access for users and service accounts to databases.
Something other thing to take into consideration is that at this time groups are not supported, only direct user and service accounts are (i.e., indirect users via groups is not supported). You will need to give your own user account the "Cloud SQL Instance User" role as well as those user accounts in that group that will use IAM based authentication to the Postgres instances in this project configured to use IAM based authentication. Note that you need at least one individual user account assigned this role in the project - you cannot just have service accounts.
On the other hand, make sure that the Postgres instance you are attempting to add a user to has been set with the flag cloudsql.iam_authentication as per the instructions here.
Next, you should be able to add the user and Service Accounts granted the "Cloud SQL Instance User" role via the 'Add User' interface as described here.
Finally, you'll need to GRANT each user/Service Account appropriate permissions on the schemas it should have access to, pay attention to the fact that the full email address of the user or Service Account is required as outlined here.

Create and active Directory Account with no priviliges

I want to know if it's possible to create an Active Directory user account that confers no access or privileges to that user.. simply to authenticate a set of credentials..
As we are hybridised AD/Azure organisation, I want this 'account' to replicate to Azure through the connector.
The reason for this is that:
We manage all our users through AD so I don't want some accounts managed only in Azure.. it would be very confusing. Centralised managemnent and support is good!
The account would ONLY be used for authenticating users into Zoom via SAML2, or any another cloud service for that matter that can use Azure as an authentication service.
No capacity to access anything within our firewall.
Your ideas would be greatly appreciated.
Gus
It depends how you define "access". By default, the Authenticated Users group is able to read everything in AD, but not write. If you're ok with that, then you're done. Just create a user and don't add any access to it.
If you don't want it to read anything on the domain, then you'll have trouble. The Authenticated Users group is described as:
A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.
Since there is no way to not have a user be part of Authenticated Users, then you would have to modify the permissions on your domain to exclude Authenticated Users. But that may cause other issues for other users.
As far as I know, the most basic permissions that any user is created can also view other users or groups in AAD. If you want to turn off this basic permission, just set Restrict access to Azure AD administration portal to Yes, then the user will not have any access rights.
Go to azure portal->click Azure Active Direcotory->User settings

Where should a Google Service Account be created? The App's domain? Or in each client's Domain?

Is a Service Account intended to be created in an application’s domain? Or in a clients G Suite Domain, on behalf of the application?
Background:
My company has a product (hereafter “The App”) which has several thousand organizations as clients, each potentially having their own Google domains. (hereafter “Organization Domain”)
We are looking to set up a sync between The App and the Organization Domain, for data that is common between The App and the Organization Domain, and want to use an OAuth2 connection, with a domain admin granting The App ‘domain-wide authority’ on behalf of their users, for offline syncing.
From the Service Account page:
... an account that belongs to your application instead of to an
individual end user. Your application calls Google APIs on behalf of
the service account, so users aren't directly involved.
and
G Suite domain administrators can also grant service accounts
domain-wide authority to access user data on behalf of users in the
domain.
Referencing the Cloud Platform Console Help Faq:
You can access data from your users' Google Cloud Platform projects by
creating a service account to represent your service, and then having
your customers grant that service account appropriate access to their
cloud data using IAM policies. Note that you might want to create a
service account per customer... (emphasis added)
It sounds like The App should be able to create a single Service Account, which all of our clients authenticate into for their Organization Domain.
The part that’s unclear:
In the Service Account page, the instructions for delegating domain wide authority seems to shift concerning where the Service Account is.
Before the instructions, it reads:
... first enable domain-wide delegation for an existing service
account in the Service accounts page ... with domain-wide delegation
enabled. Then, an administrator of the G Suite domain must complete
the following steps:
Afterwards, it reads
Your application now has the authority to make API calls as users in
your domain (to "impersonate" users). (emphasis added)
From what I’m reading, the first part reads "one Service Account for The App", while the later reads as "the service account is only able to access as a person on The App domain, rather than the Organization Domain."
Is a service account intended to be created in The App's domain? Or in the Organization Domain, on behalf of The App?
I have seen examples that have the Organization Domain admin create a service account, and then pass over the clientID/secret to the owners of The App… but I’m not sure that’s the correct approach for our scenario.
Related - Scope management:
The delegation steps have the Organization Domain admin manually add scopes.
We’d prefer to use the OAuth consent screen, which shows the scopes, and has our pages/policies linked.
Unfortunately, as far as my research has uncovered, it doesn’t look like that page is used in the Service Account authorization flow; just for other application types, which authenticate a single user, as opposed to an entire Organization Domain.
Is there a page I’ve missed in Google’s sea of documentation?
I think you are miss understanding the use of Service accounts.
Service accounts are dummy user accounts. They have their own drive account, calendar account and probably a few more. Service accounts are designed for use with back end applications server to server communication where there is no user interaction. Service accounts are preauthorized. You grant the service account access to the user data in your case by using domain wide dedication to the gsuite account. This way the service account would be able to for example send control all the users google calendar accounts.
This is why you dont need a consent screen. Another point with service accounts is you must control the data in order to set this up. If you dont control the data then you cant grant the service account access to that data.
You should be using Oauth2 if you want to access private user data owned by your customers.
As for the rest of your question is very broad and i am not really user where to start with it you might want to break it up into several questions. Take them one at a time. I am not sure i understand what it is you are trying to do so i dont think i can try to answer that part.

Impersonating list of users with Google Service Account

According to the docs, Google Apps domain administrators can grant service accounts domain-wide authority to access user data on behalf of users in the domain. My understating is this gives service account authority to access data for all users inside the domain. Is there a way to restrict which users service account has access to?
For example, an application that uses Google Calendar API to view events from the calendars of specific list of users in a Google Apps domain.
Can google apps administrator authorize application for access to some but not all users?
Thanks
The answer was to publish an app in Google Apps Marketplace. An app can be turned ON for everyone or some specific organization unit. See Turn a Marketplace app on or off for users. Organization Unit is how you can control who in organization has access to your app.
If you're an administrator, yes. You can control who uses any particular Google service from their account. Just turn the service on or off for those people in your Google Admin Console. When users sign in to their account, they see only those services that are turned on for them.
To delegate domain-wide authority to a service account, first enable domain-wide delegation for an existing service account in the Service accounts section of the Developers Console Permissions page or create a new service account with domain-wide delegation enabled. Your application has the authority to make API calls as users in your domain(to impersonate users).
Here's a useful material for Delegating domain-wide authority to the service account:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount