I'm working on an enterprise application that will be granted authority to access email data by the domain administrator. I've enabled Domain-wide Delegation for the app. But based on feedback from customers, I would like to be able to limit the access my app has to specific groups in the domain, e.g. Finance. This will allow the domain admin to give email access to our app for just those users in the company that will actually use the product.
Is there any way to restrict an app that has been granted Domain-wide Delegation to one or more specific groups or organizational units in the domain?
If you have Google Organisation Units then you can limit that way. A Finance Organisation Unit would be granted access to the Application.
Related
I'm following the instruction here: https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority about domain wide delegation.
Note: When you use G Suite Marketplace to install an application for your domain, the required permissions are automatically granted to the application. You do not need to manually authorize the service accounts that the application uses
Now my question is, how the required permissions are granted to the application? How am I using those permissions? Is it limited only to Google Scripts, or I can use the permissions from my NodeJS app?
If I can use from NodeJS (Rest), which service account should I use for that?
I am working on a application that is using google service account with domain wide delegation.
I don't want client to do setting of domain wide delegation and download private key. I could create private key using IAM api.
is there a way to achieve domain wide delegation also via API ?
Thanks
Google's IAM API is part of their Google Cloud API's. As far as I'm aware, there is no equivalent API for standard Google developer project IAM, which is where you would do anything around projects targeting G Suite API's (and the only place where there is a Domain Wide Delegation setting for a service account, AFAIK).
You can grant a service account permission at the Organization level in Google Cloud, but I'm not sure whether that has any effect on the GSuite access controls, as nferrell mentions.
We are trying to put an app on the marketplace which needs multiple client_ids
(The app is running on appengine standard with python 2.7)
a client_id for the service_account with domain wide authority
a client_id for the web application
a client_id from an apps-script library
All client_ids use different scopes. I have combined all scopes and entered them on the marketplace SDK configuration.
When i deploy the app on a test domain, only the serviceaccount seems to be authorized.
When the user then access the webapplication he is presented a grant screen which we want to avoid.
The documentation https://developers.google.com/apps-marketplace/preparing?hl=fr seems to imply that multiple client_id's are possible.
How should i configure the marketplace app so that multiple client_ids are authorized?
Is there something special i should do on the credentials configuration page of the api-manager?
Check how you implement the authorization using OAuth 2.0, Service accounts allow a Google Apps domain administrators to grant service accounts domain-wide authority to access user data on behalf of users in the domain. You can also read Server to Server Applications documentation.
Note: You can only use AppAssertionCredentials credential objects in applications that are running on Google App Engine or Google Compute Engine. If you need to run your application in other environments—for example, to test your application locally—you must detect this situation and use a different credential mechanism (see Other). You can use the application default credentials to simplify this process.
Hope this helps.
It turned out all three client_id's were being authorized after all.
the days that i was testing this, it took very long for the authorization to take effect.
At this time all scopes and clientid are authorized within a few minutes.
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
I have a Google Marketplace app that uses a service account for access user's drive account. It requires domain wide grants,
As per the doc here:
https://developers.google.com/+/domains/authentication/delegation
"""
If the service account is listed as an app on the Google Apps Marketplace, then domain-wide access to user data is granted during the installation of that app.
"""
However I cannot find a way to specify the service account id in my app, how do I make sure that the service account is indeed granted privileges when the admin installs the app
You just need to use service account when authenticating & authorizing your app to access Drive API.
https://developers.google.com/drive/web/service-accounts explains the process pretty well along with a sample.