JHipster implements several best practices for authentication and authorization.
Mainly described here: https://www.jhipster.tech/security/.
But I still do not see an example how to design a solution, which does not involve putting user verification logic all over the place for a very common use case.
Let's say you have a WebPage using REST-API like BankAccountResource from JHipster Sample App and you want to restrict this to only ADMIN role or currently logged in User. Let's say you have 50 of such services for your customers: BankAccount, Address, BillingAddress, UserData, Devices... For every resource a GET and UPDATE must be restricted. Also loading device /api/device/{id} might not include user-id.
How do I prevent UserA from loading UserB's device by guessing it's id?
How do I avoid planting that code in every method?
I guess JHipster/SpringSecurity has concept/objects to handle such use cases. Could you point me, explain how to use them please?
Maybe this question helps a little bit: Restrict URL access control by id in jhipster
Spring Security hast PostFilters to check if an object e.g. loaded by a method may be accessed. If you need more control you can use Access Control Lists for fine grained access control.
References:
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#domain-acls
https://docs.spring.io/spring-security/site/docs/5.3.0.RELEASE/reference/html5/#method-security-expressions
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
I'm using web api for my application on ASP.NET CORE
If someone see application soruce code, there is a backend url, isn't it?
Then, that guy can use my api if he succeed my application decompile
How protect that situation
I'm just stutdent, so... Just my curiosity
Authenticate your API
If you plan on having a private API (not open to everyone), then you should force users to authenticate themselves by using an API access token. Each token should be specific to a particular user, and there should be consequences for distributing a private key (such as revoking it and blocking the person associated with it) or else people will just share them without care. This will allow users to communicate with your server and run commands or queries as they please. Assuming you have written these functions correctly, they shouldn't allow an attacker to access much beyond his given scope of given API functions (which should be queries at most).
Document, document, document!
You shouldn't allow users access to your source code for this. You should document your API thoroughly regarding details which methods the user can use, what sort of data it expects to receive, and what sort of data you will get back from it (including all errors, possible problems with the users request, and how to fix their requests). Make sure you heavily test these too, and make sure that you can't perform any sort of malicious actions with your API. It's also a good idea to give your documentation to another person and ask them to read it. If you've missed something important, you will know afterwards because there will be a clear gap in their knowledge of the API.
What, not how
Users should know what a function should do, but not how it does it. For example, I could use /api/GetUserById. I should know that I can get a user - I shouldn't know how it gets the user. The only thing I need to know is that I perform this call and I get back a json object with details about the user. That is it.
As with any of my posts, if there's something I've missed or something you need further clarification on, please let me know in the comments and I'd be happy to explain further. I hope this helps
I don't want to store passwords on my server and I don't want to force my end users to create yet another account, that's why I'd like to use single sign-on. I'm looking for a widely accepted solution for the authentication, I think about OpenID and OpenID Connect, the former seems to be more widespread but obsoleted and no longer used by Google, the latter seems to be faster (thanks to JSON?), safer but less widely adopted.
I'd like to share some documents on Internet. I want to control who can view them. I have looked at OwnCloud but it seems to be too much for my needs.
My website contains some photos and some articles, I want to show some of them to everybody, I want to show some of them only to my family and my best friends but not my colleagues, I want to show some of them to all logged users but not everybody and finally, I want to show some of them to … nobody.
I use Apache HTTP Server, I want to be able to manage file access rights for my end users with their own means of authentication. I have looked at mod_auth_oid and mod_auth_oid_file, it handles the authentication with OpenID 2.0, it allows to define a mapping between OpenID and local user ids. Does it mean that I still have to store a password for each local user anywhere on my server?
A graceful server restart is required in order to load new mapping definitions
It's a bit annoying as I don't want to restart the server each time I edit the mapping. It's unclear to me whether it is still true when using mod_auth_oid_ldap. I really need an open source software that I can install on my server and adapt to my needs. I plan to use openid-selector with the Apache modules I mentioned earlier and some JavaScript code to handle gracefully the display of the forbidden content. Am I missing a more obvious solution? I'm not a big fan of Facebook but is this bridge working?
Hard to find a meaningful title. I hope I get clearer now.
I'm building a service which is similar to doodle regarding the authentication model. The user can "create" something (using a form). There will be two different views. One for the creator where he can modify his settings and another one for public access.
I don't want to force users to register / log in. So I came up with a URL structure like doodle has:
/{some-id} -> public access
/{some-id}/admin/{some-token} -> settings page for the owner
The question now is how I can deal with this best. Currently I pass the token to all admin related Methods. But I don't feel comfortable with that.
I also thought about some server side session. I found two meteor packages but they are both not actively maintained anymore.
Another idea was to misuse the built in user management but without the user to recognize it. But I don't think that's feasible.
So now I'm asking you if you have a nice way of dealing with this. I hope I made clear what I want to do.
There are many ways of doing it. One way is to reuse Accounts package.
You user id is {some-id} and the password is {some-token}.
When you create new page. You create new user on server side using Account.createUser.
When you enter url /{some-id}/admin/{some-token}Meteor.loginWithPassword.
I work for a department of a university that uses CAS to provide single-sign-on authentication, and am writing a CakePHP application that needs to use this CAS service. I need to write code that:
Checks with the CAS server to see if the user is logged in
Pulls some credentials from the server if so
Checks the credentials against an internal ACL, as the set of people who can access the application is a subset of the set that can log into the CAS service.
Provides some mechanism for admin users, either by creating special admin users outside the CAS system (with all the headaches that would entail) or by promoting certain CAS users (with the different headaches that would entail).
As a relative newcomer to CakePHP, I frequently struggle with where to stick code that "doesn't belong". The best I can figure is that this code ought to go in the beforeFilter method of the App Controller, but I wonder, is this the best place for it? Also, is it too low in the stack to take advantage of admin routing?
Lastly, I know that CakePHP provides both Auth and ACL components, but when I looked into using them they did not appear amenable to interfacing with outside authentication services. Am I wrong, and would either of these be a good fit for what I need to do?
Thanks!
If you take a look at the Cake's core components you can see that your CAS requirement fits with the type of things components are typically used for (ie. auth/session).
I would recommend creating a CasAuthComponent. There is some information on extending AuthComponent, in a previous answer of mine, which may prove useful if you wish to build on top of the existing core AuthComponent.
A component (essentially reusable controller code) can interact with models, use other components (such as Session) and control user flow (redirects for example)
Note that, the core AuthComponent actually retrieves information from a model (the User model by default), so you could do something similar.
The CasAuthComponent you create could $use an external user model (CasUser maybe) which is responsible for CRUD operations on the data (retrieving users mainly).
You could take this one step further and abstract CAS interactions into a datasource used by this model, but it isn't strictly neccessary if you don't plan on reusing the code in other models.
The end result could be packaged into a plugin:
CasAuthComponent (app/plugins/cas/controllers/components/cas_auth.php)
CasUser (app/plugins/cas/models/cas_user.php)
CasSource (app/plugins/cas/models/datasources/cas_source.php) [optional]
And used in your application by putting the following in your app_controller:
public $components = array('Cas.CasAuthComponent');
If you wish to be able to administer the users from Cake, you can also include a controller and views in your plugin, which allow the user to interact with the CasUser model (ie. $this->CasUser->save()).