In our application we are evaluating where to store all personnel information (name, email, phone, department, date of birth,date of hire, licenses/certificates, roles etc.). We will use LDAP/Active Directory for user authentication/authorization so at least some of these data will go into LDAP server. Our HR module and other applications also need some of these information and there is an overlap between them. We are thinking on storing all information in LDAP and just use user ID as a reference in our RDMS to LDAP user and populate other details of user during login process. Other than our application there will be other applications which will also use same user information. If we do not store personnel detail in ldap we will need to duplicate and synchronize user information in each system. LDAP will be needed for login information anyway. What is your recommendation on storing personnel detail in LDAP or DB tables?
Generally speaking, Active Directory isn't a good place to put sensitive PII like what you list. There's absolutely no technical reason that it can't store this data, but, securing it is more difficult. It's certainly not insurmountable, but, I would definetely suggest keeping HR data with HR and synchronizing any demographic information necessary to AD.
Use the Employee ID value in your HR system to maintain the relationship back to AD.
In our company, we built a middleware and an Intermediate Database which is updated 3 times a day. The middleware is an ABAP remote function that generates data from SAP, a C# program which uses SAP .NET connector to invoke the remote function and retrieve that data and save it in an Oracle Database.
This database is used to interchange information with Active Directory. Then systems as Exchange, messenger, SharePoint get the information of this Active Directory. Other internal systems have access to the Oracle database also. The advantage that we experienced is that we avoid the overhead that represents to access SAP and Active Directory everytime. We only access them 3 times a day but the users acces the Oracle database every second.
Hope it helps.
Related
I am a former Lotus Notes/Domino developer, learning the Microsoft stack. I am building a web application with a SQL server back end. I want to build a basic CRUD application where users register, then login. They should be able to work with data they created or that has been shared with them. I am unsure how to achieve that result.
One of the cool features of the Domino database was the ability to add reader and or author fields to each record with user IDs, or roles and the server would automatically filter out those records when a user accesses the database. So if the user opened a View or Queried the database, the server would never let them see records they were not assigned access to.
Does SQL server have similar functionality? I've seen some information on row-level security, is that the best way to secure data? If not, what is the best practice to secure data so users can only see their data?
Thanks for any help you can offer.
Yes. SQL server has Row Level Security:
Row-Level Security enables you to use group membership or execution
context to control access to rows in a database table.
Row-Level Security (RLS) simplifies the design and coding of security
in your application. RLS helps you implement restrictions on data row
access. For example, you can ensure that workers access only those
data rows that are pertinent to their department. Another example is
to restrict customers' data access to only the data relevant to their
company.
The access restriction logic is located in the database tier rather
than away from the data in another application tier. The database
system applies the access restrictions every time that data access is
attempted from any tier. This makes your security system more reliable
and robust by reducing the surface area of your security system.
But it's more common to embed the authorization logic in a server-side application like a web server or web API. Row-Level Security is more common where users connect directly to the database, like in reporting and analytics, and client/server desktop applications.
I have a rich client program installed on users PCs where I want to start storing some user created data on SQL Azure/SQL Server. The potential anonymous-to-me users would key in their name, email account and a password which would get stored on SQL Azure/SQL Server. Then they would start generating their own data. I'm anticipating volumes of maybe 1000 users.
There are times when those users would like to run their own queries against their own data but, obviously, I must ensure that they can never view other users data.
I'm thinking the best way to ensure security of data is for each user to be issued their own SQL Azure account and password. I will setup a SQL Azure user and long password, known only to me, which only has permissions to execute several stored procedures with appropriate parameters being passed to those SPs which will create the SQL Server accounts, logins and add the users to a role which I have created.
Obviously someone running debugging tools could figure out the user name and password but I'm thinking this isn't a big deal. If all that particular SQL Azure account can do is execute a few SPs so what if a malicious individual starts doing that. I will only allow a very limited amount of data to be uploaded before I require payment.
The users can only insert records using stored procedures which use the following:
SELECT #uName=SYSTEM_USER
and only select appropriate parent records. All stored procedures which users can execute would have the above as required to ensure they can only work with their own records.
All views will have embedded with them WHERE clauses such as
WHERE tbLoginName = SYSTEM_USER.
I'm new to SQL Server so I may be missing some fundamental concepts so I'd appreciate any and all comments.
The issue is, as pointed out on http://msdn.microsoft.com/en-us/library/ms189751.aspx:
In SQL Azure, only the server-level principal login (created by the provisioning process) or members of the loginmanager database role in the master database can create new logins.
Those accounts are also capable of alter and drop logins. So if you embed those accounts in the client application, you’re essentially granting every user permission to alter/drop other users accounts. While an average user won’t do that, a hacker will. So you cannot let a client application manage SQL Azure logins, unless only trusted users (such as your IT administrator) are permitted to use the app.
Best Regards,
Ming Xu.
I would like to point out a potential issue in the approach you mentioned: Your master SQL Azure account need to have privilege to create new accounts and grant them access to particular tables. This means your master account itself need to also have access to all those tables. If you store the master account on the client side, a clever user will get access to all users data.
From my experience, connecting to a database directly from a client side application will almost always make your solution less secure. You can do that for testing purposes, but in a real world solution, I would like to suggest you to use a service. You can host the service in Windows Azure. Then the service will access the database, and client application can only access the service. In this way, you can authenticate clients using any mechanisms you like, such as ASP.NET membership.
Best Regards,
Ming Xu.
You are essentially creating a physical two-tier database connection, allowing a client application to connect directly to the database. This is a problem in many ways, including security and performance. From a security standpoint, not controlling from where your customers will connect, you will need to keep your firewall rule wide open for anyone in the world to try to hack every customer uid/pwd. And instead of having only 1 user id to play with, hackers will have up to 1,000...
The second issue is performance. You applications will be unable to leverage connection pooling, creating undue stress on your database server and possibly hitting throttling issues at some point. Using a web service, with ASP.NET membership to manage logins, and using a service account (i.e. the same uid/pwd) to get data will ensure you will leverage connection pooling correctly if you keep the connection string the same for all your requests.
With a web service layer you also have a whole slew of new options at your fingertips that a two-tier architecture can't offer. This includes centralizing your business and data access logic, adding caching for improved performance, adding auditing in a centralized location, allowing to make updates to parts of your applications without redeploying anything at your customer locations and so much more...
In the cloud, you are much better off leveraging web services.
My 2 cents.
Let's say I want to create simple database, for a simple book store application. I think i should have minimum two users: admin, which has privileges to create, modify and drop objects and user, having just select and insert privileges.
I am a little confused here. Should I create a user account with normal schema or with empty schema? Should the user has privileges to select and query from admin schema which contains tables or it is a user schema that should contain these tables?
There are many different ways to approach this sort of problem. So a great deal depends on your application architecture.
You would generally create one database account that owns the database objects-- tables, packages, views, etc. Let's call this account BOOKSTORE_OWNER. This account would generally be locked so that no one could log in as BOOKSTORE_OWNER other during periodic builds.
Beyond that starting point, however, there are a host of reasonable ways to deal with authentication and authorization. If you wanted to let the database handle both, you would create two roles-- BOOKSTORE_USER and BOOKSTORE_ADMIN. Those roles would be given appropriate privileges on the objects owned by BOOKSTORE_OWNER. You would then create a database user for every person that can use the application and grant the appropriate role to each new user. So if you're an admin and I'm a user, the database account dygi would be created and granted the BOOKSTORE_ADMIN role while the database account Justin would be created and granted the BOOKSTORE_USER role.
This approach worked quite well when people were building client-server applications. If you are using a three-tier application, on the other hand, you want the middle tier connection pool to use the same credentials to connect to the database rather than having each user have their own database connections. The simplest way to accomplish this is to create a single BOOKSTORE_APP database account, grant that account all the privileges of the BOOKSTORE_ADMIN and BOOKSTORE_USER role, and then let the application implement the logic to figure out which front end user has what privileges. This would generally entail a USER, PRIVILEGE, and USER_PRIVILEGE table in the BOOKSTORE_OWNER schema. This approach can work quite well. The downside, though, is that every application has to build its own logic for managing privileges which can get quite complex over time. It also can make it somewhat difficult to report on what privileges users have or to ensure that a user's privileges are kept up to date when users leave the organization or move to a new role.
Oracle in particular addresses many of these challenges by allowing proxy authentication. This allows you to mix the benefits of the client-server approach where every user has their own database account that leverages Oracle's existing privilege management infrastructure with the connection pooling benefits of using a shared database account. This works very well but only works with Oracle and then only with certain protocols (OCI and JDBC) so it is not terribly popular.
Of course, beyond these basics, you can get into quite a bit of complexity. You may want to have enterprise users where Oracle doesn't maintain the password but instead allows the user to authenticate against an external LDAP directory. You may want to manage privileges with LDAP roles rather than with rows in application-specific tables. You may want to integrate with various middle-tier single sign-on (SSO) solutions.
I have issue where I need store info about users in DB and authorize via LDAP.
A bit more detailed.
I have two depends system which has common for users (approach something like "stackoverflow" where you can create login based on google account..).
Not all users can have access. For example, have company which have contact persons and some of them have access to developed system. That is mean persons have foring key to company and some of them must have records in LDAP.
I'm new in LDAP. Please suggest architecture solution for this.
Thanks!
Regarding LDAP to database synchronization, you could create a routine for exporting LDAP objects into a .csv file and then importing it's records to the database.
You could, for example, use LDAP's user "uid" attribute to indicate an object's uniquiness on the database.
Also, there's JDBC-LDAP Bridge Driver, that you can use to develop Java applications that can access data stored in a directory server.
Usually in companies, the employee information is stored on an Active Directory server. So I am guessing when we log on to our machine using ID/pwd, it goes and checks an Active Directory. I am wondering why Active directory is so universal in use when storing employee information.
Why not use a db? I am aware theoretically of the differences between AD and DB, but from what I know, I do not see why AD is a natural choice for storing employee information.
Here are some reasons why AD is preferred compared to a Relational Database when storung user data
AD is heirarchical so if your data is like an employee record where you have a superior then AD is a natural choice having said that AD schema consists of objectclasses and attributes rather than an a DB's tables. This means it uses objectclass inheritance model which is cleaner than linking multipe tables together.
Read performance in AD is faster then DB in most cases. But remember DB is faster in saving data.
Data Synchronizatoin happens out of the box and nearly no administration at all.
Probaly not related to your question but worth mentioning, AD already has a built in functionalities such as secure storage for hashed passwords, password policies, permissions around password changes and password resets which if you use a DB you have to build this on your own
Since AD is LDAP then you dont need database drivers to connect to it.
With AD you can have multiple values in one attribute if you do this on a normalized database you have to store each attribute value into multiple table linked to the master table.
Schema is standardized in AD so where ever you go it will remain the same
I hope this helps