Amazon Simplify manage user hierarchy with cognito and dynamoDB - amazon-dynamodb

I would like to use the AWS Cognito groups with Owner-based scope dynamoDB to manage my users permissions, but there are some particularities:
Lets say I have "Group A" and "Group B" created on my Cognito:
Group A can:
create a new user, but the new user would be in Group B only
see and update his own data ( I can manage it with Owner-based scope on tables)
see and update only users from group B that he created
give permission to user from group B to see specific data (here is where Owner-based doesnt work, since 2 or more users from group be should be able to see it, not only the owner. ALso, not all users from group be could see, only the selected ones)

Well, unfortunately it is not possible to do what I was looking for, the Amazon Amplify is a great tool, but to basic app, where you only need a simple way to give access to users see and edit their own content.

Related

Access control in Airflow

i have a problem with airflow.
Does Admin creates variables and controls access to each variable for each user?
Example: admin create Variable a, b and user userA, userB
Does admin can create role that allow userAread, edit variable a, can't edit b and userB read, edit B, can't edit a
Interesting question!
Part 1
As an admin you can create the following permissions .
So perhaps you can first ensure the users cannot delete Variables.
Part 2
If User A and only User A knows the Variable value. I would take advantage of a lesser-known Airflow feature to mask sensitive fields. I have provided 2 URLs for ways to approach this. So essentially the variable output will be masked, allowing User A to only know the answer. User B will see a variable exists however the value is masked. I believe you might also have to ensure you restrict CLI access.
source a
source b
Part 3
FYI - Airflow can automatically obfuscate any values when the variable name contains either secret or password. The check for this value is case-insensitive, so the value of a variable with a name containing SECRET will also be hidden.

Restrict view access of a Phabricator (Maniphest) Task field to only a specific group of users?

On our company's Phabricator site, for example, I have an Approver select (dropdown) field that is part of the form when I create a new Task. I want only a specific group of people to be able to see this Approver field when someone creates a new Task or edits the Task. Is there any way to accomplish this?
You can create forms for creating maniphest tasks and pre fill them with values. Therefore go to https://<phabricator-uri/transactions/editengine/maniphest.task/ .
You can additionally set permissions to different groups to grant access to these forms.
For more details just read: https://secure.phabricator.com/book/phabricator/article/forms/

Custom Authentication in Google Firebase

I have a question regarding authentication using Google Firebase.
For an app, I want to build an authentication similar to the one Slack uses: first, the user provides the input as to which group they want to log in to. If there exists a group with the same name as provided in the input, the user is then taken to a login/signup screen.
I've thought about storing users in the realtime database as follows, but I think there must be a better way to do this (since I don't think I can use the firebase authentication in this case):
groups: {
"some_group_name": {
"users": [
"user1": {
.. user 1 information
},
"user2": {
.. user 2 information
}
],
"group_details": {
"name": ..,
"someGroupDetail": ..
}
},
"some_other_group_name": {
...
}
}
I haven't realized if there is an obvious answer yet, so I'm open to suggestions. How would you suggest I tackle this?
Thanks
PS: I'm building the application using Nativescript and Angular, and (so far) there is no server or database involved other than Firebase.
Another suggestion that might work, is by using Firebase Auth Custom Claims. That way, you only need to store the group ID and group name in your realtime database, without worrying to keep changing the database each time user is added or removed.
This is one way you can do it:
Store database exactly like you have it, with it's group ID and name.
In your backend script (I recommend Cloud Function), each time a User is registering themselves, add custom claims in your user: Specifying what group is the User belong to.
Every time user authenticate, retrieve the group ID from custom claims. And there you get it!
Note: be careful not to put too much information in your custom claims as it cannot exceed 1000 bytes.
Read more about it here: https://firebase.google.com/docs/auth/admin/custom-claims
I would suggest you to implement Root-level collections.
Which is to create collections at the root level of your database to organize disparate data sets(as shown in the image below).
Advantages: As your lists grow, the size of the parent document doesn't change. You also get full query capabilities on
subcollections.
Possible use case: In the same chat app, for example, you
might create collections of users or messages within chat room
documents
Based on the reference from the firebase cloud firestore
Choose a data structure tutorial (I know you are using Realtime database but structuring the database is the same since both are using the NoSQL Schema)
For your case:
Make 2 Collections: Users, Groups
Users: User info is stored in the form of document
Groups: In the Groups Collection, here comes the tricky part, you can either store all groups subcollection under 1 document or split into multiple documents (based on your preference)
In the group-subcollection, you can now store your group info as well as the user assigned where you can store user assigned in the form of array, therefore whenever a user access the group, query the user assigned first, if yes, then allow (assuming users can view all group)
You do the thinking now

How to obtain list of common users from different groups in firebase DB

Is there any way I can find if users is present in both the groups here: user 1 so that notification/data can be sent to only that set of common users only?
As DB grows I think it will be inefficient to check if every user in one group is present in another or not.
Yes there is. You can create a list of users from GroupA, then create another list of users from GroupsB and then just simply use this line of code using Java8:
!Collections.disjoint(list1, list2);

Allow asp.net sqlmembership users to create "subusers"

I've tried searching this for days and can't seem to find an adequate answer so I'll ask here.
I'm building an asp.net Membership website.
What I want to do is:
Allow a user to create an account - say UserA
I then want to allow UserA to create "sub accounts" tied into his account, but with different roles as well as different login names (I'll be using email address as the login name)
UserA would be the account admin of sorts.
UserA's sub accounts would be less "adminish" than UserA, but any data that they write to my DB (Entity Framework) would still be tied to the main UserA account which will be referenced to my tables via Membership.GetUser() API calls.
So 2 questions:
1) How would I reference the Membership tables in my EntityDataModel using DB First (I already ran the aspnet_regsql.exe)
2) How would I need to go about allowing UserA to create his own sub users?
Here's an image of my custom tables:
[MasterAccountUser]
MasterAccountId = aspnet_Membership.UserId
AccountNumber = autoincrement number
[UserAccount] - subaccount of [MasterUserAccount]
AccountId = aspnet_Membership.UserId (if I have to have each user create their own)
MasterAccountId = aspnet_Membership.UserId (but the same one as the [MasterAccountUser]
If this is too vague, let me know and I can expand.
I was able to get this to work.
Basically, you just do the standard aspnetdb.mdf with all the in-place security features.
Then you simply add a table with the same fields, and then you reference the
MembershipUser.GetUser(Page.User.Identity.Name);
So you own table will have a "masteruser" with this User.ProviderKey. Every "sub-user" then has the SAME masteruser guid on their record so that they all fall under the same account.
If anyone want more details on how i got this to work, i can happily provide them.

Resources