I have a rather very know Solr issue. The index contain a group of docs of employee records that has a set of public access fields and a set of secure fields. Based on the user's security credentials (which may be indexed in the doc as one field), if a document matched, all its public fields and some of the secured fields which he has access. This list of secure fields varies document to document in the same index. Example: a manage of a department (belonging to one company) can view all secure fields of employees (doc) under him but not for those who do not work under him (whether in the same company or not). But he can still see ALL the public fields of ALL the of the employees (matched and filtered docs).
So being manager, I can see all (public + secure) fields of every one working under me but my asst can see only some of the secure fields who are under him. How to implement this in Solr. Thanks.
The documentation states that Solr does not concern itself with security at the document level.
Solr is designed to be an index of your data, not a replacement for your database (Access control is an important DB feature, only adds complexity to an index)
My suggestions:
Remove all sensitive data from the index. Each Solr document could include a reference (or link) to a 3rd party system/database holding the sensitive data requiring access control.
Encrypt the sensitive content within the index Using public/private key encryption, you can control who is able to decrypt the sensitive fields of a Solr document. (This solution wouldn't scale very well, nor does it allow searching of encrypted fields)
Create a sensitive search index, for each manager: Use the web server's authentication mechanism to control access to the index and load sensitive data there.
I would suggest to take the following steps:
separate out the public and secure content, you can use two separate cores.
add a ServletFilter that sits between User and SOLR webapp and then you can use some basic ACL based security on top of SOLR results to filter out the content as per your application requirements.
Related
In Azure Search we can create multiple indexes for different search results, and we have two types of api-key. One is for administation and other one is for querying. But with same api-key users can search all indexes.
In my solution I need to design a system so that different users that use the system will get different results by their previleges. I thought this could be solved with dedicated indexes for each role but still users can query other indexes if they want to.
How can I be sure that every user can ONLY be able to search on particular a index.
Out of the box it is not possible to restrict the key usage for a specific index. You would need to do something on your own.
Other possibility would be to create different search service accounts and then creating indexes in them instead of having one account. You can then grant access to your users to appropriate search service account.
UPDATE
Based on your comments, you're actually looking to restrict search results (documents) by user's role i.e. going one level deeper than indexes. To achieve this, what you could do is dynamically append this role criteria to your search query as OData Filter. For example, let's say your index has boolean fields for each role type (Administrator, User etc. etc.) and the user searches for some keyword. Then what you could do is create an OData Filter $filter where you check for these conditions. So your search URL would look something like:
https://<search-service-name>.search.windows.net/indexes/<index-name>/docs?search=<search-string>&$filter=Administrator%20eq%20true
That way Search Service is doing all the filtering and you don't have to do anything in your code.
You can learn more about query options here: https://msdn.microsoft.com/en-us/library/azure/dn798927.aspx.
We make heavy use of dynamic datasources. We retrieve server name and database names from a table in a SQL Server database. A package loops through the server names and database names and executes once for every server, for every database.
These values are then put into the ServerName and InitalCatalog fields of the dynamic connection. User and password are pre-defined (and therefore the same for every connection). I would like to fill the user + password from a table too but then I have to store the passwords as clear text in that table.
Is there a way to store the password encrypted in that table and decrypt it when I need to use it? Any person having access to the SSIS package is allowed to know the passwords but they should not be easily read from the table containing the connection strings.
All suggestions to handle this (f.e. using different approaches) are very much appreciated !
The preferred solution is to keep using integrated security.
Normally the job will try execute the step under the account of the SQL Agent, that is not what you want.
Proxy account is a replacement for the credentials for the SQL Agent account (msdn.microsoft.com/en-us/library/ms175834.aspx), also not helpfull in this case.
I remember that on Windows 2000 we used a trick by creating same local accounts with identical username and passwords on all servers to overcome the SSO limitation, it will probably work in your situation.
Yes, you can encrypt/decrypt a column. See Microsoft's walkthrough here:
https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-2017
Best practice is to then create a view that decrypts the column and then grant user-level (i.e., SELECT, ALTER, INSERT, UPDATE, etc.) access to the view only because the view must have the symmetric key to decrypt the data. Exposing the key can be a security vulnerability, so you want that locked down as much as possible. A view with limited user access is the best place to allow a key to be exposed (if there is ever a good place to expose a key, which there is not).
But, Ako is correct. Use integrated security.
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 have the following requirement: Retrieve the users from OpenAm which are members of a specific group. Alternatively, if possible, retrieve users defined in a specific data store. All this through web-services.
We have our own JDBC data store implementation which reads users from and authenticates users against our database. That works fine. The data store is one of two data stores in our sub realm. The other data store points to an LDAP.
Now I need to read the users (and later the user attributes) from users being defined in the LDAP data store, and only users of a specific group, if possible.
Previously we did that with wso2. There they had a web-service method that allowed you to retrieve users of a specific group only.
Currently I am looking into the IdentityServices web-service of OpenAm, and I am able to list all users of my realm, and get the attributes. But for performance reasons, it would be nice to be able to refine the search. Is that possible? Am I looking at the wrong web-service?
Regards,
Sascha
We have an asp.net web application which maintains a table with user information, passwords and roles. I am trying to import this information to a Membership database and ultimately use them for Form Based Authentication in a Sharepoint 2013 web application. I also noticed that the Membership database which I created does not store passwords. At this point I am a bit confused as to how to proceed with creating a FBA for my sharepoint site using the same member credentials and roles from my existing table.
It does actually store passwords. You probably have it configured for ‘hashed’ passwords – so you can’t actually see the passwords in the table – only a 1 way hash of the passwords. If you set the passwordFormat to Clear, the passwords will be in plain text within the db.
That being said, for security I do suggest you use Hashed. Do a search on google on how to hash your existing passwords so they can be put in the db in the correct format. But if you want to get it up and running quickly, use Clear and then Hash them in the future once you’ve got everything working.
And just a note - the password field is on the aspnet_Membership table.