I want to make an App Maker application that contains sensitive data. How do I make it so only certain users or groups can access the application?
Your application is automatically restricted to members of your domain, but if you’d like to further restrict usage you can edit the settings of a particular deployment of your application to restrict usage. Under “Application access” click “Only allow access to specific users”, then you can add any combination of users and Google groups. Note you can only add users and groups within your domain.
There are also lots of other security issues you might want to consider. Review https://developers.google.com/appmaker/security/overview for more details.
Related
I'm using Microsoft Graph SDK for .NET Core. I'm trying to get a list of all Office 365 plans in all Azure Active Directory groups within my organization.
I have been reading through a lot of questions, but haven't found a clear answer to my problem: As it's stated in the official documentation, you cannot list plans in a group using client credentials (application permissions), which is the exact authentication method I'm using. Given this, how can I achieve my objective?
As per documentation, the only way to list plans in groups is to use Delegated Permissions, but in that case, and according to the Microsoft Graph permissions:
either the user or an administrator consents to the permissions that the app requests and the app can act as the signed-in user when making calls to Microsoft Graph.
If the signed-in user is a regular user then the application will only access the groups that user is a member of. Bear in mind that there may not be a single user that is a member of all groups.
Is there a way to get my application to list all plans in all groups within my organization?
You can now use application permissions.
Outdated Reply:
Planner currently does not support application permissions. Depending
on what your scenario is, you have couple of options. One option is to
create a user account to be used by your app, and add that user to all
the groups. Then you'll be able to query the plans with the
credentials of that user.
I want to be able to add domains to Firebase hosting with the API instead of the web UI, is that possible?
I want to add potentially hundreds of domains, is there a domain limit per project in Firebase?
As far as I can tell from the entire CLI documentation, there isn't any way to do this.
Lets take a step back and consider what the web UI process involves i.e. the generation of a TXT record to add to your DNS records, after verifying the presence of said TXT record on the domain, providing A records that you (authorized owner) add to allow redirecting to your firebase hosted site.
In my opinion, this very manual back and forth is necessary as a security measure. The only way it is taken out of the equation via the CLI is by providing a means for you to authenticate ownership of a domain (registered with any one of many domain registrars), and being granted authorization to change your A records. These are both outside the scope of Firebase, and could potentially introduce severe security flaws. Regardless, even if it existed, it would still have to be step-by-step and somewhat manual via CLI rather than the single command it sounds like you're looking for.
It is not possible to add custom domains automatically through an API at this time.
Nor would it allow you to create a reseller or multi-tenant project (i.e. connect a large number of domains or subdomains dynamically) since you cannot connect more than about 36 domains connected to one project.
It's possible to add domains using Firebase Hosting Rest Api. I am not sure why they didn't put it on their official website but I checked today and it works. https://developers.google.com/resources/api-libraries/documentation/firebasehosting/v1beta1/java/latest/com/google/api/services/firebasehosting/v1beta1/FirebaseHosting.Sites.Domains.html
Answer that I've received from Firebase support:
There is no API yet that would allow you to add custom domains, it was
requested as a feature before but unfortunately we have no more
information on that - so for now, only the Console UI allows you to do
it.
When it comes to the limits, in a project, a custom domain is
attached to a site - there can be 36 sites per project, and for one
site there is no hard limit, but we recommend not exceeding 20 custom
domains. You can experience technical issues with SSL certs when you
exceed 20 domains per site, which we won’t be able to troubleshoot
since the system was not designed for such use cases.
I have a saas platform I'm building and I'm currently struggling with how to model my auth flow. The system is going to be multiple multi-tenant applications but I would like to unify user authorization & authentication. Basically, each US State will have its own web app/resource server/database and every county in that state will be a separate tenant. I cannot combine all states into one application, so that is not an option.
I would like to throw all users and their information/password into one database connected to my auth service. But each county (tenant) admin within each state (web app) needs to be able to add & manager their users and their roles. So the auth service needs to be aware of all the different tenants across each application. I also need to be able to link items created in each database to the user that created it. If I create object "X" and another user in my county views that item, they can see "Kovaci" created this.
I also do NOT want SSO between states but if possible I would like users to be a part of multiple tenants within one app (not a requirement though). Native iOS/Mobile apps are another client I need to support with this flow.
I used this bitoftech article to base off of: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/comment-page-1/#comments
And here is my paint quick mockup: multi saas design
My question is just generally how do I design this auth part? Can I store all users in one auth db like my goal? If so, how do tenant admins manage them and how do I link tables in my separate app db's to the users' current info in the auth db?
This is my first attempt, trying to integrate Membership on an existing shop already in production.
I'm not quite sure, based on my scenario, if I should use the build-in aspnet-providers or custom implementations of them in order to integrate membership.
Here's a few details:
I have a multi-tenant, single database, single schema web app based on subdomain.
The app is already in production and I will later want to link newly registered users with existing anonymous orders by email.
The development will continue after the membership integration, new features will be added, meaning new columns and linked tables for the users table.
This answer got my thinking of using the membership deafult Profile in order to extend the users table created by the aspnet providers, since I don't have users yet. Though its not clear to me how I would link Users with Orders and other tables/entities that might later be added when the app is going to be extended.
Maybe I could define my entities related to users as user-defined profile properties but they would not have associations on my database.
Another overhead I'm thinking of is how would I associate the users with the different tenants of the app. I would want users to be able to regiter in different tenants/subdomains with the same email.
How would you implement membership in this scenario?
This question is an aggregate of a few questions. I will try to answer them to he best of my knowledge
In case of managing users, i would like to suggest that you consider the following approach
Pre-define a list of basic user profile metadata that you will need in the application
Create an extensible approach like having custom fields for the user profile so that it can accommodate any data that may be required to capture in future
You should also be planning for a self-registration system in the application that will allow your user's to register themselves like the anonymuous ones that use the system with an email
Regarding associating the business entities, you will require to associate the entities with the tenant and not with the user. the level of application will be from the tenant and then it will flow down to the users.
Additionally, you should not have the user accessible business entities, when they are maintained in a form of package or so, it will be very easy to manage and use.
Share your thoughts on these approaches.
- Create a tenant identifier column [property] for each profile that identifies the base tenant to which the user belongs to
- create a table that manages the list of other tenant's that the user may be gaining access to at a later part
A project I'm working on supposed to authenticate users agains AD. I've never worked with AD before, neither did I work in organizations that use AD, so here's my stupid question: in case if AD involved, who manages roles, groups and users for application? Is it my responsibility to provide an UI for site admin to assign AD users to my app roles or AD admins should take care of creating appropriate groups expected by my app and assign existing AD users there?
What are the best practices in this department?
Once thing to note -- this is not an in-house app, so it is supposed to work with an existing AD. The question is if my expects roles like "Teachers" and "Students" (just to illustrate the point), may I expect that IT people will create appropriate groups in AD and assign users to them?
I don't think you should supply a Gui for active directory. Most organization that use active directory manage it with the standard active directory tools.
If you want to handle the case of small shops. Then make the groups internal to the application DB. You will still be able to use the active directory users. But the group management and membership will be internal to your application. This will avoid most problem of dealing with the complex rules of active directory, and still benefit from single sign on.
One more thing to note. The group names should be customizable. Most places have naming convention for group names.
If you're writing this app for another company, I think you could assume they'll be in charge of managing the AD users and groups. You'll just need to coordinate with the clients on what roles/groups your app will use.
This really depends on who owns the AD, and who is going to be responsible for managing user accounts. If this AD is isolated from your coporate domain, and you want your support or sales, or other business person to manage the accounts then by all means create them an admin tool.
If your trying to tie into your existing AD, then you should work closely with your IT department, they will probally want to create the accounts their own way (especially if your using your existing credentials).
Essentially this boils down to how your IT operates, and what exactly the relationship btw the AD your using and the AD which runs the coporate site.
Edited
Based on your additional info, I think you need to offer an admin concsole. Especially if you want to target the smaller shops out there. Your solution should make it optional so if they want to use the admin UI they can but if the IT department wants to use Powershell for example they can do that as well.