I have developed and published a simple Marketplace App needing access to all members of a domain. I followed the Google Instructions (see http://goo.gl/XvczDQ) and created a service account (for domain-wide delegation of authority). Everything is working if I access the users from my own company / domain.
But it is not clear to me what happens if an administrator from a different company installs the app from the Google Marketplace. How can I access the users in the client's domain and how works the service account approach there? What are the further steps?
I figured it out myself. Provided that the service account is correctly configured with the required scopes: All you have to know is the client's administrator email and the domain. Usually you can get this with the setup url in your marketplace app.
Then you have to set the service account user to the administrator's email before you request an access token. That worked for me.
When the admin installs the app, he grants you the authorization to use the service account to impersonate his users.
You can also list the users using the Directory API if you need the complete list of users. Note that you will need to have the relevant Directory API scope in your marketplace app configuration and you will need to impersonate an admin user.
Related
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.
I'm planning on building a G suite integration with my existing SaaS site.
I want Gsuite admins to allow access for their organisation. So I only want "domain install" possible.
After this has been done users can be imported from Google into our application. Users should be able to use SSO to login but I don't want each user having to pass the consent screen.
I also want the app to have readonly access to the calendar of the user.
What is confusing for me: do I need to create a regular web app integration or a Service account integration? I don't really need offline access but I want to avoid all users having to grant access individually.
Here it says: The user sees the OAuth Consent screen only once; if you’re using a service account to allow a domain admin accept terms on behalf of the domain users, then the end users must never see the OAuth consent screen.
So does that mean only service accounts allow this?
Yes, using a service account you can install and authorize one app for all your domain user impersonating the admin account. In such a way, your users won't have to authorize the app individually.
You will have to enable domain wide delegation in order to impersonate the admin account when using a service account.
Reference
Service Account
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.
Working off pages like this, I have a "service/daemon" test app working with the O365 mail REST API: i give consent to the app, an app-only token is granted via a X.509-signed client assertion, and i can read info from an arbitrary mailbox. It works great.
But our app will be installed for various clients on their private machines -- so it's like a native app, but we need the global permissions that app-only tokens are required for (which is why we aren't a native app).
Since access tokens are granted only based on our app credentials, i think they won't work for us: Customer A could get an access token for Customer B's private data using just the app credentials and the Azure AD tenant ID.
Is there any way to "require client secret for app-only token generation and restrict calls to this tenant ID"? I could then make a secret key for each customer.
Or if a cert could be restricted to a particular tenant ID, we could make a separate cert for each customer.
Having each customer define an app of their own isn't a realistic option, as it's far too complicated for them, requires cert generation, editing the manifest, etc etc.
Maybe there is a back-door way to get app-only style global access with a 'native app' architecture? E.g. if our customer has an admin account, could we authenticate with the 'native app' style oauth grant for that one admin user, and access all users' email via that account's permissions?
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