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.
Related
I have been reading through multitenancy in hibernate and couple of post from stackoverflow but it seems they are not addressing the requirement that i have, so here it is. I am working on a SAAS based application model where i have one application been served by multiple customers, and for every customer there will be a independent instance of the tenant database(postgresSql). Apart from this i also have a master database that will be used to authenticate the user and to identify which tenant database it belongs, consider this master database will have information like the connection URL to the tenant database.
When the user logs in i will authenticate it with the master database get the tenant database information like connection URL and connect to that database and serve all the users request through that.
Considering the fact that i can define multiple sessionfactories in the hibernate config file, which will make it static during application development, instead i would want to create the sessionfactories dynamically for the respective tenant database for which the user belongs by reading the information of the connection URL from the master database.
Also, there also will be a scenario where in i will have to maintain the sessionfactory of the master database and the tenant database as there will be a requirement where i will have to add users to both master database and tenant database during user creation.
Can any one help be address this requirement?
I would define two sessionfactory, one for the master db and one for the others dbs starting with fake values. this can help you on how to change the datasource at run time.
Finally threadlocal can help you to store data between calls.
Hope it helps.
i have an ASP.net (.net 4, c#) web application (Backend: SQL Server 2012). The permission concept (what data is each user allowed to see) is processed within the web application.
The permissions come from different sources:
-AD group memberships:
AD group name is linked to properties of the records
-Underlying database:
-Users are assigned to different criteria
Organizational structure
Location structure
Direct assignment
Currently all this is processed within the web application. So I collect all the users permission and then I query the database for the data he is allowed to see.
Now I need to bring the permission concept to database level.
The target is that the users can query the database (pre defined views) almost directly (Reporting Services, Excel and so on)
Any idea how to solve such an issue?
Thought about joining the user’s permission on the foreign keys. But that’s not possible for the AD permissions.
Or maybe creating a dll and calling this dll from a stored procedure. Then the view joins the stored procedure.
You should look at defining roles in the database http://msdn.microsoft.com/en-us/library/ms188659.aspx .
Then grant permissions on different tables or views depending upon your requirement. I have seen data being exclusively read from views. So, that could also be an option.
EDIT:
So, it looks like you need row level security. Please read this guidance from Microsoft.
http://technet.microsoft.com/en-us/library/cc966395.aspx
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.
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.
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