I am running wso2 governance registry with a JDBC backed primary user store and a Active Directory backed secondary store. What I want to be able to do is create some groups in the primary store (which I have done) and assign users from the secondary store into those roles.
I have done a lot of looking around the wso2 site and google and come up with nothing. I guess my question is, is it possible and if so how do I do it?
Cheers
Matt
AFAIK, this is not possible. For roles (or groups) created in one userstore, we cannot assign users from another userstore.
However for an internal role, you can assign users from any of the available user stores.
Related
We currently have an Azure Active Directory tenant, which replicates via AD Connect our on-premises Windows users. We have an on-premises Exchange Server where accounts are my-company.com.
We have another email domain my-company.io for which there are no users yet.
In the immediate future, we want to create a few mailboxes for my-company.io directly in Exchange Online (not on our Exchange Server). These mailboxes will not be attached to Windows domain users.
Later this year, we want to start migrating our my-company.com Exchange mailboxes to Exchange Online, gradually with a hybrid setup.
In this scenario, what does make more sense?
a) Create second tenant in our Azure account, create there any my-company.io AAD users, then add these users to Exchange Online.
b) Add another domain to our existing tenant, create there any my-company.io AAD users, then add these users to Exchange Online.
Our concern is if activating Exchange Online for my-company.io users in the existing tenant, will interfere in any way our future plan to migrate to Exchange Online for my-company.com users.
Both methods should be feasible. The difference is whether the two accounts exist under the same tenant. If you have a reason to let them exist under the same tenant, you should choose the second option. But if you do not require them to exist under the same tenant, creating a new tenant for my-company.io is recommended, because this will reduce the configuration when migrating to Exchange Online for my-company.com users.
Your concern is not superfluous, but they are not unsolvable. If you choose the second option, then you need to carefully design what your hybrid deployment environment is like. For example, there are two types of users, one is a hybrid deployment user, and the other is a cloud-only user. You can refer to this document to choose the configuration you need.
In short, from the perspective of easy configuration and management of different types of users, the first solution is better, while the second solution does not require you to create new tenants and requires you to pay more attention to configuring hybrid deployments.
The Problem
Good Morning! I work on an application team that supports a few applications which utilize SQL Server for data storage. Recently, our Database Support team decided that SQL Authentication was no longer permissible (for security and logging reasons) and so my team was forced to convert all connections to Windows Authentication including several dedicated Service IDs that our applications had been utilizing for data retrieval.
First, let me say there most certainly are advantages to moving to Windows Authentication, I am not trying to dispute that. But this change has raised a huge problem for us... by switching our Service IDs to Windows Authentication we have now opened up our back-end databases to every internal business user with front-end application access.
MS Access is pushed out to every user desktop and a few superusers even have access to SSMS. At this point we are relying entirely on user ignorance to prevent internal users from accessing the back-end database directly. And given that certain roles have elevated DML rights, this presents a possibility for some nasty data consequences.
This new enterprise standard has left my team stuck between a rock and a hard place at this point so we looking for any database, account or architecture solution that would allow us to restrict user access to front-end only.
Questions
Has anyone else run into this problem? Is there an architectural solution we are missing that would allow us to eliminate SQL Authentication without exposing our databases?
Does anyone know of a way to restrict access to a SQL Server database to only certain connection methods? I'm wondering if there is a way to designate a specific ID (or role) as only allowing a connection through a front end (and eliminate ODBC connections entirely).
Does anyone have any clever workarounds?
-------------EDIT---------------
A couple people brought up a good point about role access so I wanted to clarify our former and current solution... Previously, all role access was managed on the front-end and data retrieval was handled entirely by private system SQL Authenticated IDs to which end users had no visibility.
When we were forced to eliminate these SQL Auth IDs, we created a similar role-based setup on the back-end database as existed on the front end. Active Directory Groups were created to house different groups of users and these groups were assigned specific role privileges in the database. So currently access is limited by role as much as feasible.
The problem is that even the lowest privileged roles have INSERT, UPDATE and DELETE access to some tables (access which is normally controlled through code). So while we were able to mitigate risk somewhat by utilizing database roles, we still have areas where a user can bypass front end protections by logging directly into the database.
EDIT: Question clarification makes this answer obsolete, but leaving it for reference since some comments discuss it.
Assuming you mean that you have to (based on your architecture) allow access to the DB to each windows user account, one options is to use database roles.
You disable public access to your database, then define a set of database roles, depending on your use cases. Each role is granted permissions such that members of that role are able to manipulate the data they need and or work with the objects they need. Users are then mapped into the roles they require. When connecting to your database, the user will be granted permissions according to the roles they are members of.
For example, we have a role in one of our databases named MyAppUser (our name is actually related to the app which uses the db), which is designed for end users to read and insert data only. These can be created simply as follows:
CREATE ROLE [MyAppUser]
The role is granted just the permissions it to the relevant schemas or tables (assume all our "public" tables are in dbo schema for now).
GRANT SELECT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT INSERT ON SCHEMA::[dbo] TO [MyAppUser]
GRANT DELETE ON SCHEMA::[dbo] TO [MyAppUser]
Each user who should have this public read-write access is then mapped into the relevant role.
ALTER ROLE [MyAppUser] ADD MEMBER [UserName]
This separates users and roles / permissions within your database and allows you to have a single point of entry to control who has access to what in your databases.
By having the "View Definition" permission denied by default (to end users), they won't be able to "explore" the database / view table definitions etc using access, or even SSMS.
NB: SSMS provides wizards for managing and viewing permissions and memberships which are very handy for getting things initially setup / tested / fiddled around with.
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 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