How do I create a system user? The goal is using this user as an administrator.
I can only create normal (client) and server (something like client) users, but I'm unable to create a system user.
I tried the Atlas App Services Admin Rest API but there I can do just the same I can here.
I see that a possible solution is adding custom user data but there isn't a way in the console.
Any solution?
A server user is for backend access to your database. This may be useful if you are looking to perform backend database administration.
When you use Atlas App Services, you are creating users for frontend access to user-appropriate data. If you want to create users on the frontend with a role/privilege of 'Administrator', then you need to implement that logic.
You can create custom data for users, which is a separate document linked to the user with additional fields. A simple implementation would be a custom field 'isAdmin'.
A rule would need to be implemented to only give your frontend users access to restricted data once 'isAdmin' === true. For example:
{
"%%true": {"%%user.custom_data.isAdmin"}
}
For more rule examples: https://www.mongodb.com/docs/atlas/app-services/rules/examples/
Related
I have an existing API connected to an AWS PostgreSQL database that uses AWS Cognito for User authentication.
The goal is for users to insert data via the API with some field mapped to their Cognito id, and retrieve the same data. The idea would be for each user to only have access to the data 'owned' by them. Similarly to the way row level access works.
But I do not want to create a role for each user which seems to be necessary.
The idea would be that I need to somehow setup a connection to the PostgreSQL DB with the user_id without creating a user and handle the accessible data via a policy, or somehow pass the data to the policy directly.
What would be an ideal way to do this, or is creating a PG user for each user a necessity for this setup?
Thanks in advance
EDIT: I am currently querying the database through my backend with custom code. But I would rather have a system where instead of writing the code myself, the PostgreSQL system handles the security itself using policies(or something similar). I fully understand how PostgreSQL row-level-access works with roles and policies and I would prefer a system where PostgreSQL does the major work without me implementing custom back-end logic and preferably not creating thousands of PostgreSQL roles for the users.
You should not allow users to make a direct connection to the database.
Instead, they should make requests to your back-end, where you have business logic that determines what each user is permitted to access. Your back-end then makes the appropriate calls to the database and returns the response to the user.
This is a much 'safer' response because it prevents users having direct access to your database and it is also a better architecture because it allows you to swap-out the database engine for another one without impacting your service.
The database is for your application, not for your users.
There is an Apache Atlas server. The user connects using ldap technology. Users are adding the atlas-simple-authz-policy.json config file.json and specify its role in the application. We are faced with the following situation, until you create a user on the server itself (useradd nickname), the user will not receive full access within his role. I.e., in fact, the user will be able to log in to the application, perform some kind of search that will display the result, but it is already impossible to view the contents of the fragments found.
Consider the following scenario: you have a SSO service (let's say Keycloak), and X applications, that have their own databases, where somewhere in each database, you're referencing a user_id. How to handle this? How to satisfy the foreign constrain problem? Should one synchronise Keycloak, and the applications? How? What are some best practices? What are some experiences?
I've been using Keycloak for several years, and in my experience there are several scenarios regarding synchronizing user data between Keycloak
and your application's database :
Your application is the owner of the user data.
Keycloak is only used for authentication/authorization purposes. In this scenario, your application creates/updates a keycloak user using the admin rest API when needed.
Keycloak is the owner of the user data and you don't need more info than the userid in your database.
In this scenario everything regarding users could be managed by Keycloak (registration, user account parameters, even resource sharing using the authorization services).
Users would be referenced by userid in the database when needed.
NB: You can easily add custom data to the user in Keycloak using the user attributes but one interesting possibility is to extend the user model directly using this : https://www.keycloak.org/docs/latest/server_development/index.html#_extensions_jpa
Keycloak is the owner of the user data and you need more than just the user id (email, firstname, etc)
If performance is not an issue, you could retrieve user info via the Admin Rest API when needed.
If performance is an issue you'll need a copy of Keycloak's user data in your app's database, and you would want that copy to be updated on every user changes.
To do that you could implement callbacks in keycloak (using SPIs: https://www.keycloak.org/docs/latest/server_development/index.html#_events), that will notify your application when an user is created/updated.
NB : You could also use a Change Data Capture tools (like Debezium: https://debezium.io/) to synchronize Keycloak's database with yours.
There's pros and cons to each scenario, you'll have to choose the one which better suits your needs :)
I'm using Node.js with Loopback (based on Express) for the REST API. It has an ACL implementation that allows you to give/prevent access from/to parts of the API to a Role.
The front-end of the application is written with React and Redux.
The app will have a public and a private part, and I want people to be able to log in to /admin.
Next to the ACL for the REST resources, should there be a separate Authorization mechanism for the front-end?
Say I want to be able to access the #/admin page and my user is part of a role that allows you to look up information about users; How do I decide that my user can access the admin dashboard and how do I decide that my user may add a widget that makes use of the users API, to which his Role has been granted access?
Use flashboard for loopback admin dashboard.
Its automatically generate your admin panel based on your models configs.
vah7id.github.io/flashboard
I want to implement database authentication in mongodb.
In order to do that, I found out that I need to first create an admin user and then create separate users for each of my database through mongodb client shell (manually or using a javascript file).
I was wondering if it is possible to add user to the individual databases from the spring application itself but did not get any useful pointers to do this. Is it that this approach is wrong because if this possible the application will always be able to access the database because it itself is creating the user, but external access will still be blocked.
Please let me know how this can be achieved or if it is an incorrect approach.
After you add a normal user via the MongoShell, you can then connect via your application and create either normal users, or read only users.
Note that a normal user can also add users, so the users your application adds may need to be down as read only users depending on your use case and needs.
In the MongoShell, adding a read only user can be done via
use myAppDB
db.addUser("JohnSmith", "CheddarCheese", true)