I'm working on a nodejs app, which can have users using multiple languages. So my design is creating lang1.example.com and lang2.example.com sites for respective languages. So that it's easy to manage each language with its own database.
At the same time, I don't want users to create different accounts for each language - so that they can keep using same credentials across the different domains.
To do this, I'm planning to sync the credentials in users collection across all the databases. This syncing will happen whenever an user creates an account Or user changes credentials(password, email, etc.).
The other fields in the users collection will not be synced - such as user followers, user's language specific activities.
However, I'm not feeling confident about above design approach since it will involve a lot of syncing between the databases.
What could be an alternate solution so that I can avoid such syncing ?
Related
I am currently designing an application with many organizations, and each organization will have many users. My concern is about the data privacy and security of these organizations/users. It should never happen that organization A would see data of organization B and vice versa.
I want to use PostgreSQL and Node.js (Nest.js), but the technology does not play a strong role here.
I wanted to have one PostgreSQL database where each organization has its schema, for example, orgA.organizations, orgB.organizations, etc. Unfortunately, I found that it is not a good solution. With many schemas, there can be a performance problem. Then I was thinking about database per organization, but it seems like a huge overhead to handle ~1000 databases.
Now, I am thinking about having a "flat database structure" - without any schemas and having just one database. Organizations would be just in one table and the same for users.
The concern with data privacy would be solved primarily on the application level - I would check if user A can access the data of organization A. Still, in the database, these data will "live together".
So, my question is - what is the best way/technique to ensure that user A that belongs to organization A, will never see the data of organization B?
I am currently working on a web app that will have to handle users and user privileges (like in most web projects). I intend to develop it around Node.js which seems to solve most of my constraints. But I have been advised to use an "Active Directory"-like structure for privileges management and query it using LDAP.
So I'm wondering, is it still relevant nowadays to use an "Active Directory"-like structure to authenticate users/handle privileges ? Node seems to have enough to offer regarding that aspect (I'm thinking of Passport) with a storage of the Users and their privileges in a database.
In my data model, I know that I will have to deal with Users, that belong to Departments. These departments have Projects, that Users can belong to (multiple or none). I thought a relational or a non-relational database was going to be the perfect match, but now I hesitate.
Thank you
The biggest benefit of using Windows Authentication in a website is if an organization is already using Active Directory, because it can enable seamless login. Your users wouldn't have to put in their credentials at all, and you already know who they are.
Setting up an Active Directory domain just for user management of one app is way overkill, for sure. For example, Lynda.com has a 2-hour course just about installing Active Directory.
Using something like OpenLDAP would be simpler, but still overkill in this scenario.
They're designed to manage, not just users, but computers, groups, policies, relationships to the external world...
If all you need is user and permission management for one application, then you're better off using something else.
I am working to create POS(Point of sale) application using couchdb with angular. Since i am beginner to NoSQL world. Need guidance to how to design the system.
It should be cloud based application, where login user can create companies and each company has n locations.
In relational database sense, my database design look like this.
While logging to my application, username & password validated against license db. If they are valid application will connect their own company db.
Whenever user create new company, new database will be created, all their locations, invoices, payments are in their own db.
License db responsible for user accounts, payments and their plan and level of security(which screen they can access/edit).
The application has offline support using PouchDB. where relevant location details are downloaded to user browser, and they synced back to server DB.
Questions:
Is it ok to create database for each company.
If user wants offline operation, they can sync own location data only(filtered replication), if they want to access other location data, application should connect cloud DB.Is it possible?
I want the same code to query/insert data in couchdb & PouchDB. Is it possible?
Is couchdb map-reduce/mango query support complex reports
Is Angular+Couchdb is enough, or do I need any server side framework.I don't any third-party authentication right now.
How the above relational database design should be implemented in couch db
what are the other things i should think about this software design
Yes. One common design for CouchDB is to have a database per user. One per company is totally reasonable.
CouchDB supports filtered replication. You could setup a filtered replication for user's documents on a local database instance (PouchDB or CouchDB)
PouchDB allows you to connect to CouchDB. Basically, you could have a PouchDB library that does all your business operations. You would only need to change the database adapter for the cloud or client database.
Map/Reduce is pretty straight forward. It allows you to index documents and query them by their keys. You can easily change the values in your indexes and also use reduce functions. Mango queries are more flexible. A bit similar to MongoDB.
You might eventually needs an application layer but that's possible to use only CouchDB.
I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?
Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...
You could do it either way. First about couchdb users
Users in couchdb are stored in a special _users database
Database permissions are handled by a special _security document. This is specific to every database.
In security documents you add users that you have already stored in the _users database previously.
So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.
Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:
Store your "business logic users" in the special _users database.
Authenticate it with the _session endpoint.
Extract the cookie header and sent it with your application headers.
All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.
If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.
The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.
If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store
It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.
It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.
A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules
The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.
You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.
I work in a large company, and I'm interested in best practices for internal security standards. We have a large ($500 million +) investment in SAP, and we also have .Net and a bit of Java EE in our internal environment.
I've found some documentation from MS and SAP, but it's outdated and not very specific.
So far, it looks like we could end up using Active Directory as the standard user store for all non-SAP applications, and SAP CUA / Portal for SAP applications.
Some concerns I have about AD are:
Being able to aggressively time-out for applications on shared computers (A small number of our applications run in remote offices in rural areas with a limited number of shared machines. In these cases, a supervisor with "power user" privilages could use an application, and then a clerk who should have only basic privaleges could use the same machine immediately after)
Being able to force the user to enter a username and password instead of just having the credentials read from the user's workstation - Because it's pulling the same credentials for the desktop and email, it won't currently ask users to log in. This is a concern for applications on shared computers as well. (See the explanation in the previous bullet)
As far as synchronization between AD and CUA is concerned, I want to approach this very carefully. We have a limited budget, and I want to make sure that if we end up putting something in place to synchronize the stores, that it's rock sold and provides excellent value. If we can't find something like this, I'd be comfortable coming back with a recommendation that the stores remain independent. SSO would be ideal, but I've worked with trying to get an SSO application up before SAML, and it wasn't pretty.
Acronyms:
SSO: Single Sign-On SAML: Security
Assertion Markup Language
CUA: Central User Administration (For SAP)
There is a lot of possibilities on this subject.
We had a customer that updated both their AD and their SAP user list from SAP HR. The idea was that the OM module contained all employees. You could export daily a list of all active employees to the LDAP, with basic informations (firstname, lastname, employeeId, login...). For the SAP system, unit/function/job needing a sap access where tagged and user where created/removed daily.
In fact, all employees had a SAP account, but only those tagged had a "dialog" one. Those account are allowed to connect via SAPGUI, others had to use the portal, which is a less costly licence. A set of rules allowed to set the roles for the managed users. The goal was to minimize user management and limit the inexorable grows of autorisation that comme from moving from job to job an organisation. (this was for 105000 employe, with a lot of personnel movement).
Thus SAP was not directly linked to the AD, but they where synchronised. Depending on the system (Development, qulity, integration, production), SAP was configured with time-out. You could also have différent password for separate systems.
Of course the reverse is also possible : interrogate a LDAP from SAP to manage SAP's accounts, without beeing directly linked to the LDAP. transaction LDAP can problably give you some informations.
hope this helps
Edit : the synchronisation was done by an ABAP program. that program was run every day at four, and created/deleted/modifed some accounts in the LDAP. After that, another program added some technical informations to the LDAP entries, informations that where not available to the SAP RH system (such as the mail server to use for a given employee, depending on its location around the world). The entries where then checked for consistency, and send to the master LDAP.
This program only managed personnel and units. Groups (authorization for others application) where managed either manually, or by others programs. Thus non SAP data were also stored in the LDAP.
Regards
Why is it a problem if users don't have to log in? Wouldn't that be more convenient for users? And wouldn't it give them further incentive to log out of the application?
The project I'm working on now uses AD, and we have a mapping table inside of SAP to map AD accounts and SAP accounts. Syncronisation is manual, which may or may not work for you, but there's no real technical risk.
I wish I could give you more information, but I haven't been very involved with that side of things. I can look into it,though.
You might want to look at OpenSSO - it has agents for SAP and it will integrate with AD as the user store. It's also pretty solid - Verizon use it for 40 million customers to log in to their web site.
IMHO.
This is not good solution to use different users in one windows session. Especially users authenticated in AD.
Usually it will be going that USER1 running sap client without closing , and work another USER2.
You get non-personified users. And don't forget users don't like perform all instructions.
We used thin client like citrix and SSO. It is full split data and authorization between users. And you have to use different sessions for users on workstation. The good think is no critical data store on workstation.
Not good idea and not secure but you can use run as different users
application in Windows environment in same session. But it is not secure solution for big company.