some questions about service accounts and best practises on GCP.
1) I'm able to create a "brand new" service account. How can I ensure that this new service account doesn't have any kind of privileges bound to it? I'm asking this because for a project I need to create multiple service accounts with only one permission: write access to a single Google Storage bucket. Nothing more. How can I ensure that this is the only granted permission and nothing else ?
2) Should I create a new Google Cloud Project for every customer I have, in example, one project for each website that I'll host to GCP or a single company project (in this case, my company) would be enough to hold all Compute Instances, Storage buckets and so on, needed by my customers ?
Managing hundreds of project would be overkill, if possible, i prefere to avoid this, without impacting secutiry.
Thank you.
You can only constrain service account permissions to enabled services that implement IAM (the Google Cloud Platform services including Cloud Storage). For services that don't implement IAM, the only way to limit a service account's auth is through OAuth scopes.
Projects appear provide a more robust security perimeter for you to separate your tenant customers. Additionally, you get enforced separation of billing, logging, auditing etc. It's debatable whether managing per customer projects (each owning a bucket and related service accounts) has different security than a multi-customer project (with many buckets and service accounts) since service accounts may be easily extended across projects. I recommend whichever path you choose, you ensure control is effected programmatically to minimize human error of granting one customer's account(s) to another customer's bucket(s).
HTH!
Related
I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
I want to use Drive & Sheets API from Python3.
I tried to create a service account in GCP console, but it said You already have credentials that are suitable for this purpose, without telling me what role of GCP makes it suitable.
Now I want to find and add the role to my favorite service account. I do not want to create a new one, nor use the already-suitable ones.
What is the name of the role which allows using Google APIs?
I think this is confusing and poorly explained in Google's documentation but IAM and OAuth scopes are mostly (now) complementary technologies. I consider IAM to refine or provide more granular, account|credential-specific scopes
Scopes came first and IAM came later.
IAM -- actually Cloud IAM -- applies only to Google Cloud Platform (GCP) services.
OAuth scopes exist for all Google's APIs (including those of GCP).
https://developers.google.com/identity/protocols/googlescopes
In your case, Drive and Sheets are part of G Suite and not included in Cloud IAM. There are thus no IAM roles for you to assign to your service account that apply to these services.
For GCP services, it is customary (though seemingly redundant) to use both IAM and scopes.
Often you'll see https://www.googleapis.com/auth/cloud-platform used as something of a catch-all|default scope.
UPDATE: In retrospect, I should add a qualifier to this, OAuth scopes are effectively redundant for service accounts. In the case of a human|user-based OAuth flow where the end-user is delegating authority, the scopes remain relevant as they summarize the permissions for the end-user to review before granting to the code.
I am currently setting up an ASP.NET MVC application that will be hosted on the Windows Azure platform. The application may be used by hundreds of third parties, each with their own group of individual users, which will need to be authenticated by logging in. I am looking at using Windows Azure Active Directory (WAAD) for the authentication piece.
Obviously I can use WAAD to set up individual logins for each user, then add them to a group which has been set up for the third party they belong to.
This will likely be sufficient for most third parties. However, some may already have their own Active Directory (AD), which may or may not be a WAAD, with all of their users as members. I am wondering if there is a way that I can, relatively easily, provide a way for them to connect their Active Directory to my WAAD, allowing their directory users to authenticate with our WAAD.
I have read about integrating an on-premises AD with WAAD, either through synchronisation or using a federated login. However, all of the articles seem to be aimed at "your" on-premises AD linked with "your" WAAD. Obviously since you manage both directories there is inherent trust there. However, for obvious reasons, I only trust third parties to authenticate their users and do not want to open up a mechanism where they may be able to manage my WAAD and affect other people's users or groups.
So...
Can I connect a third party AD with my WAAD and let them authenticate their users for my application, without compromising the security of my WAAD?
If so, what is the best way to configure this set-up? Would I use the standard federated services software, for example, or is there something more suitable?
1) You can definitely expose Azure AD applications to users from other Azure AD tenants, without the need to manage their directories or give them any access to yours. The Azure AD documentation refers to those kind of app as "multi-tenant". You can find a detailed example in https://azure.microsoft.com/en-us/documentation/samples/active-directory-dotnet-webapp-multitenant-openidconnect/.
2) multi-tenant applications operate under the assumption that all the participating directories have their corresponding Azure ADS tenant. That is the case when, for example, they did set up Office365 or any other cloud service. Direct federation would not work in this scenario, given that the just in time provisioning of apps and the enforcement of permission and access rules relies on the directories and users being stored in shared infrastructure (though still completely isolated form each other, as is always the case in sound multitenant systems).
Please try the sample, hopefully it will help making the above more concrete. HTH
You can also look at the Azure AD B2B and B2C (in preview) options - https://blogs.technet.microsoft.com/ad/2015/09/16/azure-ad-b2c-and-b2b-are-now-in-public-preview/
I'm working for a non-profit that is trying to create a collection of services that will allow them to do a few things:
Create/Manage Users
Create/Manger Competitions
Create/Manager Events(a Competition is made up of many Events)
Logistics
Etc.
Here are some of the requirements:
Host on Azure
Accounts are created using the user's own email address (can be any domain)
Each service must be independent of each other
System should be accessible from anywhere(browser, mobile app, etc.)
Once a user logs in, access to other systems should be available(if needed or depending on permissions)
-services can talk to each other(we've successfully done a POC on this using Azure Active Directory)
I've spent some time researching the possible ways to tackle this, including looking at articles like this:
http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
It sounds like JWT is the way to go, but I want to make sure that this architecture approach lends itself to flexibility down the road. I'm willing to learn/user any technology as long as it plays along .Net, Web Api, and MVC.
My initial idea was to set each "system" as a Web API, which is pretty straightforward. My concern is authentication/authorization. The million dollar question then becomes:
How can I authenticate a user on a browser/mobile/desktop app and then make use of the other services(APIs), where each service can verify if the user is authenticated independent of other services.
For example, lets say I am using the web app(browser) and register as a user(using User service) in order to register for a competition(Competition service). what kind of technologies/architecture would need to be used for both services to use the same authentication mechanism?
I am not new to MVC or Web API but I am to a scenario like this, so all help or advice is greatly appreciate it. For any that are interested, this is the non-profit: http://worldjumprope.org/
They are doing some cool stuff in terms of outreach and spreading the love for jump rope. Their goal is to be able to help people all around the world and provide a way to for them to come together and compete. They've been doing it for years, growing each year, all for free and out of pure passion for the sport. Help me help them!
Azure Active Directory can help you with your need.
About the security/Auth mechanism, simply put, it is like you get a token from Azure Active Directory to be able to use it to do authentication for a certain Audiences/Tenants.
And in your architecture, when you acquire a Token, you can specify if you are going to use it against a certain audience or it will work for a list of audiences or all audiences in a specific tenant or in a multi tenant scenario.
Here is a link to a video about AAD Single Sign on:
https://azure.microsoft.com/en-us/documentation/videos/overview-of-single-sign-on/
You can download the AAD Solutions arcutecture from here:
http://www.microsoft.com/en-us/download/details.aspx?id=45909
Also maybe worth looking at Identity Server - https://github.com/IdentityServer/IdentityServer3.
Same concept as Azure AD in terms of tokens, but perhaps with greater options for what you choose as a data store for your user information.
There are lots of demos and source code on the site, particularly around the different types of authentication flow \ service to service authentication
I have a Rails app acting as an OAuth 2.0 provider (using the oauth2-provider gem). It stores all the information related to users (accounts, personal information, and roles). There are 2 client apps that both authenticate through this app. The client apps can use the client_credentials grant type to find users by email and do other things that don't require an authorization code. Users can also log in to the client apps using the password grant type.
Now the issue we're facing is that the users' roles are defined globally on the resource host. So if a user is given an admin role on the resource host, that user is admin on both clients. My question is: what should we do to have more fine-grained access control? I.e. a user can be an editor for app1 but not for app2.
I guess the easy way to do this would be to change the role names like so: app1-admin, app2-admin, app1-editor, app2-editor, etc. The bigger question is: are we implementing this whole system correctly; that is, should we be storing so much info on the resource host, or should we denormalize the data onto the client apps?
A denormalized architecture would look like this: all user data on the resource host, localized user data on each client host. So user#example.com would have his personal info on the resource host and have his editor role stored on client app1. If he never uses it, app2 could be completely oblivious of his existence.
The drawback to the denormalized model is that there would be a lot of duplication of data (account ids, roles) and code (User and Role models on each client, separate management interfaces, etc.).
Are there any drawbacks to keeping the data separate? The client apps are both highly trusted--we made them both--but we are likely to add additional client apps, which are not under our control, in the future.
The most proper way to use oAuth and other similar external Authorization methods as I see it, is for strictly Authentication purposes. All the business/authorization logic should be handled on your server part at all times, and you should always keep a central record of the user, linking to the external info per external type of auth service.
Having a multilevel/multipart set of access, is also a must, if you want your setup to be scalable and future-proof. This is a standard design that is separate from any authorization logic and always in direct relation to business rules.
Stackoverflow does something like this, asking you to create an actual account on the site after you login using an external method.
Update: If the sites are really similar you can subset this design to an object per application that keeps the application specific access rules. This object has to also inherit from a global object that has global rules (thus you can for example impose a ban application-wide or enterprise-wide).
I would go for objects that contain acess settings, and roles that can be related to instances of both application level settings and global settings only for automating/compacting the assignment of access.
Actually you can use this design even if they are not too similar. This will help you avoid redundant settings and meaningless (business-wise) roles. You can identify a role purely by the job title/purpose, and then impose your restrictions by linking to an appropriate acess settings setup.