I'm trying to implement fine grained / granular permissions on users in my REST API (expressjs / mysql).
My web application contains member groups.
Each member group has a single administrator (user).
I don't think JWT would work here because when claims are stored in a users JWT token, if the administrator of the group changes, then the old user might still have a claim on their token thats invalid.
For example:
user1 becomes administrator of group g1
user1 has token1 which allows admin actions on group g1.
user2 becomes the new administrator of group g1.
user1's token is still valid and contains claims which allows admin actions on group1.
How do I go about implementing a per-object level authorization mechanism in nodejs where a user -> performs action -> on object?
PassportJS handles authentication but im unable to find good information about implementing authorization with the above complexity.
Does it make sense to store the permissions information in a database and query the database and perform authorization validations?
Related
I have a simple ToDo app written in ReactJS with Express backend and MySQL. I've recently implemented Auth0 authentication, and the app successfully requires authentication before allowing a user to view or add tasks. Any user can see all the tasks (stored in DB), but at least authentication is required first.
Next, I want ensure that users can see only their OWN tasks. Can anyone either describe how this works, or share any decent resources on the subject? Any examples I can review somewhere? I imagine there is probably an ID value I can fetch from Auth0 user DB and silently include that as a column in the DB, then allow users to only fetch tasks matching their own ID.
Any resources appreciated.
I want some guidance as to how to go about this:
I want to have some objects in my S3 bucket by accessible only be a few users (users from my web app). I looked through the AWS docs and it seems as though I need to give each of my users AWS access keys(?).
Obviously I don't want to do this, so is there any way in my app to lock out some users and let other in? I'm using Node.JS and MySQL (to store my users) if that makes a difference.
Thanks a lot for the help.
The very simple description of the S3 access / permission scheme is...Access to S3, like most other AWS resources is based on IAM-centric access controls. So, you can either grant access to your S3 buckets by either granting users access to it (setting it on S3) or granting S3 access to a user (setting it in IAM as a policy). So, whatever or whomever is accessing S3 must be authenticated to AWS. Again, that is a very high-level description and meant to simply point out that access is based on user/role authentication.
Now, assuming your web-app is running on AWS (EC2?), than your EC2 instance has been (hopefully) assigned an IAM role. Once that IAM Role has been assigned the permissions to do so, the application running on the EC2 instance can now access any AWS resource via that Role.
But, you don't want ALL of your webapp users to access S3, so my two thoughts are:
1) Check the users credentials within your app (assuming the user needs to authenticate somehow with your application) and make the determination of whether or not to call S3 based on the users credentials. You would then use the IAM Role assigned to the EC2 instance (an EC2 instance can only have 1 IAM Role assigned to it) and access S3 or not.
This second idea is a pretty bad one and smells bad to me. I'm pointing it out merely as a possibility and to highlight how the use of IAM Users / Roles works.
2) This suggestion would not utilize the IAM Role assigned to the EC2 instance, though I would always advocate for assigning a Role to the instance, you can always lock down that role and deny access to all AWS resources, but you can't add a role to the instance after launched.
Have two IAM Users (S3Granted and S3Denied, each of which obviously have appropriate policies for accessing S3). Each user of your webapp (e.g. Hillary Clinton, Donald Trump, Bernie Sanders and Ted Cruz) would then each map to one of the two IAM Users based on whether or not they should have access to S3. This would be a field in your MySQL database. You wouldn't bother checking the credentials up-front (because then you would just be performing Option #1 and would proceed with the S3 call regardless of the user and S3 will either grant or deny access based on the IAM User account your webapp user is associated with. You technically wouldn't need the S3Denied User (you could just have no user), but I figured it would be cleaner to specify the IAM User.
e.g.:
WebAppUser/Bernie Sanders --> IAMUser/S3Granted
WebAppUser/Hillary Clinton --> IAMUser/S3Denied
WebAppUser/Ted Cruz --> IAMUser/S3Granted
WebAppUser/Donald Trump --> IAMUser/S3Denied
For Option #2, you would then need to store the Access keys for both IAM Users m(S3Granted and S3Denied) somewhere so that you could properly authenticate.
Also, you would need to do a bit of exception handling so that you could properly notify your users that they have been denied access.
Overall, #2 is just a bad idea. It would be much cleaner if you simply had a field in your MySQL database that specified whether or not they can access S3 and either make the S3 call via the IAM Role or refuse to do so within your webapp. Don't leave it to S3 to grant or deny access.
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
We want to provide seamless access for all our users to SP's like publishers. The SP's are independent and provide services to a lot of different companies, i.e., we each have independent IdP solutions.
We want it to work as if there were no authentication, i.e., the user find a link on the Internet and follow it. If the site provide special services (that we pay for) for our users we would like them to use our own IdP (but only for our own users) to authenticate them.
Our current SAML setup requires that the SP support IP-address recognition and/or use specific domain names, i.e., the user access a specific domain name or come from our IP-ranges so the SP knows which IdP to redirect to but if our user comes from any other IP-address and don't access a specific URL the system is lost.
How is this solved?
I think a cookie given by the SP every time the user gets authenticated (from our network which the SP recognizes) can solve this but is that the standard? And it is not really a solution as it requires that our users have visited them at least once from our network!
This isn't so much a SAML question as it is an identity provider discovery problem which isn't specific to the protocol. How is a publisher supposed to know / decide that a particular user should be redirected to your IdP via SAML or any other protocol? This isn't a tractable problem in a general sense. The publisher and you will need to agree on a contract between two entities (you and these publishers) when it comes to these special users / services.
One possible implementation of IdP discovery that doesn't involve domains or IP ranges is a dynamic lookup of the IdP based on the user's identity. User clicks a link, navigates to the publisher site and attempts to login with (for example) his identity of myname#mycompany.com . The publisher can then do a lookup of mycompany.com in their identity store of special users / services / IdPs and determine that this user should not be allowed to login with local (publisher-managed) credentials. Instead, the user should be sent to some 3rd party IdP via a SAML authentication request. The publisher can do this at the time of user login but before the user has a chance to enter their publisher-managed credentials, be it via your favorite AJAX technique or some other form of UI gratification.
The publisher could use a persistent cookie so that the next time this user comes to this publisher they'll know that this user "belongs" to a 3rd party IdP and redirect accordingly.
We used to have an application connector implementing the Document List Service v3 to upload documents to users account. Now that the service will be discontinued starting as of next Monday and we need to migrate to the Drive API/SDK we have the problem to migrate our current login schema .. we are unable to use the OAuth 2 protocol and we need to authenticate users with their username/password credentials.
DocumentsService myService = new DocumentsService("xxx");
myService.setUserCredentials(username, password);
The reason is that our application scans and processes documents asynchronously from MFD devices (printers) and all processing/storage job is done in a different moment on processing servers, thus the limitation that the processing service cannot ask any consens to the user.
We do the same for other online cloud storage application (e.g. Dropbox) where they allow special 'OAuth 1' schema on request for such 'enterprise' situations.
How can we do this with the new Drive API/SDK? I couldn't find anything about that in the documentation rather than the service account, also looks like not suitable.
What you need to do is request authentication from you user once. The server gives you back a refresh token. Your automated application can then use this refresh token to get a new access token. You only need to ask the user one time for authentication. Then everything can run automated.
A service account wont really work in this instance because its meant for use with an account that you the developer own not a users account