I am looking for information about databases per instance in JanusGraph and couldn't find proper documentation for it. The main concern in the security boundary between the databases in one instance. Let's say there are 2 databases in one instance of JanusGraph. Is it possible to configure security such that user A only has access to Database1 and user B only has access to Database2? If so, how is this security handled.
In JanusGraph as it exists today, a "database" would be a separate Graph, each of which must be defined and instantiated at server start. JanusGraph adheres to the TinkerPop specifications, so it is run with the Gremlin server, which comes with its own authenticators: http://tinkerpop.apache.org/docs/current/reference/#_security_and_execution.
The out of the box authenticators only authenticate for server level access. However, with this PR being merged into TinkerPop: https://github.com/apache/tinkerpop/pull/583, you can write a custom authentication scheme that takes into account graph level access.
Also note that this PR: https://github.com/JanusGraph/janusgraph/pull/392 is currently open in the JanusGraph repo which will allow for the instantiation/creation of graphs, i.e. "databases", dynamically (post server start). Take a look at the GraphManager class there if you end up implementing a custom authentication scheme that takes into account graph level access, and if you do, you should commit your changes upstream into OSS.
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 am working on a JavaEE project with WildFly, Hibernate (JPA), C3P0 and a MS SQL Server database.
The database is a legacy database with more than a thousand Database Objects like Stored Procedures, Functions, Views, Triggers and so on. All these database Objects have fine grained Permissions set on User Role level.
Now I need to access this database with a JavaEE Web Application. My Problem is, that the usual JPA configuration let me set only one Username/Password for the Database in the configuration file. I can not find any way to configure the JPA layer so that will access the DB with the Enduser's Login.
I ended up to create one EntityManagerFactory per User by calling
EntityManagerFactory entityManagerFactory =
Persistence.createEntityManagerFactory(properties_with_credentials_here)
once per user.
The problem with this approach is, that this will basically instantiate the whole JPA layer per User and eat up way too much memory. I am not using any sort of Cache layer, of course. The memory is used just for the Entities meta information (which is a lot).
Now my original question: Is there any 'standard' way in JavaEE (JPA) to access the database layer with the Enduser's Login and Password?
I can not believe that I am the first person to encounter this situation. It seems to me, that 'impersonation' is quite normal in .net Web Applications. So there must be way to do this in Java, i guess.
Any comments or hints or new approaches are highly welcome.
The 'standard' way in JavaEE is to have an application user for accessing the database and achieve user-based access-rights through roles in your application.
If you need to rely on existing database user, your only chance is to establish a connection per user or per request. The entity manager would then indeed consume some memory as it's designed to be your application's persistence context (and thus some sort of cache).
Maybe you can have some trade-off here by accessing those parts which really have to be user-based by plain JDBC and potential execution of database procedures and others by some application user with extended rights which ensures the necessary user restrictions programmatically.
We have developed an SQL based application for Motorsport and some of our clients are looking at Azure to hold the database. Trouble is they travel around the world to races and as such will need to access the database using what-ever Internet connection they have and cannot pre-define IP addresses in Firewall rules. Is it possible to effectively disable the Azure firewall so that they just need to enter login credentials to the SQL server rather than having to be on specific IP address ranges?
Given the whole idea of the SQL database is access anywhere it is difficult to believe that you have to define access based on IP addresses but I can't find anything which suggests otherwise!
Before giving you mode advice on security, to answer your question, Yes you can allow All inbound to your Azure SQL Database using the following T-SQL
EXECUTE sp_set_database_firewall_rule N'Allow Azure', '0.0.0.0', '255.255.255.255';
The range above allows all. This basically means this range is permitted to pass through firewall. This is for database-level firewall rule. For logical server-level rule, just setting the rule as follows
If database-level firewall rule is not set, the logical server-level rule is applied first.
First, giving direct access to your database over the Internet is a very bad practice from security perspective. Business/End-users are not often well trained in security awareness and the very high chance their computers are compromised. There are some approaches you should consider doing to improve security:
Use built-in Azure SQL Database security feature in Azure such as Transparent Data Encryption (TDE) to always encrypt your databases. If possible, use Azure Key Vault to store the encryption master key to add more encryption layer to the "whole" world. Another feature is Dynamic Data Masking but I don't think it is useful since you allow database access level. Of course, masking some fields is worth considering. Plus, enable Threat Detection to monitor if any anomaly queries (e.g. SQL Injection).
Integrate with Azure Active Directory to monitor access identity. Every access which is authenticated by Azure AD can be monitored and notified. In Azure AD, have a look at Conditional Access policy to see whether it is applicable to your business users. Saying all business users only travel to just a list of countries usually or they use managed computers. Azure AD (Premium) also gives you Sign-In Risk functionality which combines both Analaytics and Machine Learning to identify if a sign-in is potentially risky (from unknown person). If looking at Azure AD as an option, and more stronger then consider Azure AD Universal with Multi-factor authentication options.
Establish an Azure VNET, then configure Point-to-Site (P2S) VPN to your Azure SQL Database. Fortunately recently Microsoft announces the ability to control inbound to your Azure SQL Database inside a given VNET. After setting P2S VPN, give to your business users certificate. Such a certificate needs to be installed on business users' laptop before they can connect to the VNET. Attackers without having access to their computers have no way to connect to your Azure SQL Database.
Add an application layer (e.g. ASP.NET) and login page to let your business user access from this web application. This perhaps adds development efforts but this can help to eliminate at least some direct attack to your database connection string such as brute-force. In the application, handle SQL query to reduce direct SQL Injection. This way requires in-depth understanding of development.
If financial budget is limited, I'd highly suggest you to apply Azure AD and VNET first. Below is the cost drafting:
Azure VPN Gateway: $29.2/month ($0.04/hour * 730). Basic plan is enough. The plan supports up to 128 P2S connections. If your number of business users are greater than 128, just create a new VPN Gateway.
Azure AD: if you target to Free plan, you can store up to 500,000 users. If you like to use Conditional Access and reporting, you need to pay $6/user/month for Premium P1 plan
Azure SQL Database Auditing & Threat Detection: $15/logical server/month. If Auditing is enabled, you are charged Blob storage but the cost for Blob should not really a concern.
Azure App Service: if adding an application layer. The cost is around $60-70/month for small plan (Basic or Standard). Cost also includes development and deployment effort.
What I've said here may add more concerns on the effort, cost to build. Well, I'd leave that decision consideration to you. Just one thing, think about data breaches and your business reputation if an incident happens. The cost would be much more than the implementation.
I strongly advise against it, but if it's development database, you can create an AllowAll rule in the Firewall: How can I allow unknown users to access my SQL (Azure) DB?
Better option, is to use a VPN server so that the users have to log in to the VPN to have access to the database. This way the Db is not accessible to everyone. You can further secure the VPN by adding a sign in certificate so only owners of the certificate can log in to VPN.
My guess is that you have several options:
securing the database with Azure Active Directory users. Each user can login tot the database with specific rights you could also make them readers and disabling the firewall. You could even implement row level security.
Create a Azure API application that performs the actions on the database. Let the users login with there credentials to the api and pass those credentials to SQL server.
I think that in combination with row level security is one of the most secured options. On my blog: msftplayground I created a set of articles about it.
I have to use ASP.NET MVC 3 or above and SQL Server 2008. As per Multi-Tenant Data Architecture post, there are 3 ways to implement multi-tenancy
Separate Databases
Shared Database, Separate Schemas
Shared Database, Shared Schema
I have following details:
User should be able to backup and restore their data.
No of tenants : 1000 (approx)
Each tenant might belong to different domain(url).
It must support monitoring and management of tenants.
It must support user authentication and authorization for each tenant
It must support tenant customization(enable disable features set)
No of tables in each tenant: 100 (initial)
I would like to know what your experience says about which approach is more suitable for the project considering Economic and Security? Is there any good real time example(open source project) similar to this? I can use one dedicated server for the project.
Your requirement that users should be able to backup its data, can be achivable more easily with approachs 1 and 2... since it will be a native database task.
If you are in approach 3 (shared-shared), you will need to develop the logic to extract all the rows belonging to a single tenant and export it in a xml file or something like that. Then if you need to allow users to restore that backup file, you need to develop a restore logic.
I think this is the only requirement that could make you move away from #3.
Once you set your database using TenantID columns in your table... you can easily use one database for 1 tenant or a small group of tenants if your client is heavily concerned about security. For instance, you could have one database holding tenants that are not paying (free/demo accounts) and paying customers in another one. This way you are using approach #3, but being able to behave as #1 if you need it.
::: BONUS :::
AUTHENTICATION:
You will need to extend the SQL Membership and Role Providers used in your MVC3 app... so that a user login is valid only in the Tenant it belongs to.
MULTIPLE DOMAINS
Here you can see some approaches using ASP.NET MVC3 Routing:
MVC 3 Subdomain Routing
I would always use (3) Shared Database, Shared Schema.
If you want an example, how about Wordpress, Joomla, or any other popular open source web-based project?
Creating separate schemas or databases on a per-tenant basis will lead to massive management overhead. Not to mention increased complexity of analysing your data, costs, etc.
The only reason you'd go for (1) (or perhaps 2) is if you were to give your actual tenant direct access to some/all of the database. As you're using ASP.NET MVC 3, this isn't a consideration.
We are building an hosted application that uses MS SQL Server Analysis Services 2005 for some of the reporting, specifically OLAP cube browsing. Since it is designed to be used by very large global organizations, security is important.
It seems that Microsoft's preferred client tool for browsing OLAP cubes is Excel 2007 and the whole infrastructure is geared around Windows Integrated Authentication. We, however, are trying to build an internet-facing web application and do not want to create Windows Accounts for every user.
It also seems that there are not many nice AJAXy web-based OLAP cube browsing tools (fast, drag-and-drop for dimensions, support for actions, cross-browser etc.) As an aside, we're currently using Dundas OLAP Grid but have also considered RadarCube and other more expensive commercial solutions and are still thinking of taking on CellSetGrid and developing it further - if you know of any other cheap/open solutions please let me know!
We are therefore planning on providing two modes of access to the cube data:
Through our own Web Application using one of these 3rd party Web-based OLAP browsing tools.
Direct access from Excel over HTTPS via the msmdpump.dll data pump, for when the web version is too slow/clunky or user needs more powerful analysis.
For the web app access, the connection to the SSAS data source happens from the web server so we can happily pass a CustomData item on the Connection String which indicates which user is connecting. Since we potentially have too many combinations of rights to create individual SSAS roles for, we have implemented dynamic dimension security that uses a "Cube Users" dimension in conjunction with the CustomData item from the connection string and limits the Allowed Set of various other dimension members accordingly (via other Many-to-Many dinemsion relationships with Measure Groups that contain the 'rights mapping')
See Mosha on Dimension Security:
http://www.sqljunkies.com/WebLog/mosha/archive/2004/12/16/5605.aspx
This all seems to work fine so far.
For the 'direct connection' from Excel, we set up the data pump for HTTP access
(see the MS Technet article) but have enabled anonymous access, relying again on the Connection String to control access since we don't have windows accounts.
However, in this case, the connection string is controlled by the user (we push a .odc file from the web app, but a curious user could view & change it), so we cannot rely on users to be good and keep the CustomData=grunt#corp.org from changing to CustomData=superuser#corp.org. As it turns out, this also causes the same problem with Roles, since these are also specified on the connection string if you are not using Windows Integrated Authentication.
The question therefore boils down to this: is there a way of getting basic authentication in IIS working without windows accounts in such a way that it can be used with the SSAS data pump to let SSAS know which user is connecting so that dynamic dimension security can be used successfully?
(This is my first q on StackOverflow and probably the most complicated question I've ever asked: let me know where I haven't explained myself very well and I'll attempt to clarify)
Basic authentication will work with local user accounts (non-domain) and even support passthrough authentication if the local accounts exist on different machines, however you should force SSL as basic authentication sends passwords in plaintext.
You can use non-windows accounts with basic authentication in IIS with add-on such as http://www.codeplex.com/CustomBasicAuth, but SSAS will still need to know who that user is and as far as I know SSAS uses only Windows authentication.
For a (relatively) cheap thin client front-end for SSAS look at RSInteract. For bonus points it will also consume SSRS reports and report models.
Any attempt to use dimension security will require SSAS to be aware of the user and have their access rights available to it. I don't see any way to get around maintaining user permissions.