We are exploring a few options, need to understand if there is a feature to limit user per project in Kiwi TCMS?
Looked up in the documentation could not find anything.
There are groups and permissions but the way the Django framework works doesn't actually allow to have these per object. There is nothing like projects within the base Kiwi TCMS application itself. That is to say if you have permissions to access something that means pretty much access to everything else of the same type within the application.
However there is a multi-tenant add-on, which provides a more powerful isolation layer. The isolation is done on the basis of a name space (e.g. domain name) + database schema. Additionally for each tenant admin must configure which users can access it. If you want true isolation (per team, per project, etc) then you should use the multi-tenant architecture.
This is what Kiwi TCMS itself uses to host our SaaS offering.
Source code and info can be found at https://github.com/kiwitcms/tenants.
Related
I'm evaluating the above three identity management technologies and wanted to try to find out the advantages/disadvantages and get a sense for when I should be using IdentityServer3 over the other technologies. I have three scenarios:
Internal MVC Client to Web API
External Phone Client to Web API
Internal Web API to Web API
Brock Allen's Comments:
According Brock Allen, the creator of IdentityServer:
Well, the main thing that differentiates IdentityServer is the ability
to customize the entire token service and have control of the user
data. SaaS products are very limited in customization because for the
most part they don't let you upload arbitrary code to alter or change
behavior and they often encapsulate the database of users. On the
other hand, this means you have to host IdSvr (which can be cloud
hosted) and you need to build a database for your users. So if you
need the control, IdSvr is a good choice.
Also, I should note that very often IdSvr is used in conjunction with
other identity providers (like ADFS or AAD). IdSvr is deployed in
between the apps and the ultimate IdPs, again, usually to allow the
customization that the apps need, yet still centralized and
consolidated.
Source
My Own Findings
Disclaimer: I looked into this for use by the company I work for, who had existing infrastructure I had to cater to, so the solution I chose is skewed in that direction. Even so I've tried to give an impartial summary of my own thoughts during my research.
Azure Active Directory
Azure Active Directory is a hosted identity solution, so there is far less setup (especially if like me, you discover that you are already using it for Office 365). Out of the box, it provides some very nice features that can get you started very quickly.
The premium version has monitoring and reporting capabilities (Connect Health) so you can see who is logging into your system, it has two factor authentication, an identity management website and Microsoft is monitoring logins (a bit like cloudflare for identity), so it should in theory provide some added security. However, the customization of the UI is very basic, you have to pay for the premium features and using the Azure Portal to do identity management (if you go with the free version) is kind of a pain.
The documentation is pretty good and there are samples on GitHub with Microsoft devs actively monitoring the issues which was helpful. Some links I found useful:
Documentation Home Page
Documentation for each flow
Samples covering every flow
Introduction Video 1 and Video 2.
Build Videos 1, 2, 3.
IdentityServer
IdentityServer is the Swiss Army knife of Identity management. It can do everything but does require a small amount of setup and a little more knowledge of the identity space. It can do most things that I listed above and a lot more beyond.
It has to be noted that even if you are using Azure Active Directory, there may still be reasons for choosing IdentityServer which I had not initially considered. For example, if you have more than one source of user data e.g. You are using AD and also a SQL database of users, then IdentityServer can be used to point to both of these sources of user information. In theory it should also make it easier to switch from AD to something else entirely as it decouples things.
The project is actively developed, has code samples for all the authentication flows and you can get answers from the community. Some links I found useful:
IdentityServer4 GitHub
Samples covering every flow
IdentityManager (A separate application for handling users, groups and roles).
Introduction Video
Authentication Flows
Fact: Security is hard. There are lots of different ways of doing authentication called flows. I put this link here because I found it very useful for understanding them.
(source: azurecomcdn.net)
Summary
I discounted AWS Directory Services as it's very young even though the company I work for uses AWS. We also use Office 365, so I discovered that we already had an Azure Active Directory linked to an on-premises active directory server. Even so, IdentityServer is still a valid contender for reasons I explained above. We are still trialing both solutions...
What you decide to choose depends entirely on the problem you have. Which should you choose? Well, it depends on the number of developers, time, money and effort you can expend setting this up. There is no one size fits all solution. Really, the differences in the two products above are the differences between a SaaS and PaaS solution.
We have a BI team that have created a wonderful data warehouse that works fine for the internal staff using it through Excel on the internal network. They use windows authentication through the domain controller, and everything works fine, including restricting the access to users and AD Groups.
The issue is that we now want to provide the same access to a wider audience that is not part of our Windows Domain. This is further complicated by the fact that the information on the users that need access to the system is already stored in another location (an application with a SQL database).
The goal is to make it so that they connect (probably using HTTPS) to the cube (using Excel Analysis services integration), and be authenticated using the Username/Password that they had in the main application.
The main application has a WCF Service interface for user authentication, and session management, so all I really need is a way to provide authentication in front of the MSMDpump.dll against that WebService. We can also add in a Role Mapping so that we can define the SSAS roles against the users in the application.
I was thinking that I could create a dll that has the same interface as the MSMDPUMP.dll, and have that translate calls between the client and the main dll, but this seems a bit of overkill.
Are there any pre-built tools to do this? (and yes I know that Sharepoint can do something like this, but that's not an option so please don't suggest it). Does anybody know of any blogs detailing how to do it?
Any pointers in where to start with creating an interface between the 2?
The question is similar to How to secure MS SSAS 2005 for HTTP remote access via Internet? however, I'm looking at providing the authentication mechanism from another datasource, and providing the Roles to SSAS, not the users. We don't want to have to setup a new user in SSAS for every user that is setup in the external application.
UPDATE: To be clear, they external users need to connect to the cube using Excel, and the data returned needs to be filtered by the role they're in and the security applied in the Cube.
We are able to cahnge the cube to use Dynamic Dimension Security and use CustomData attributes if that helps.
The eventual solution ended up being a combination of a Third Party Control and Dynamic Dimension Security.
We found that it's not possible to easily apply a MembershipProvider interface to the MSMDPUMP interface without significant effort, so our solution gave them a Web Interface to use instead.
The Control we used was by DevExpress and is their "PivotGrid" control. It's not free, but is significantly less than the development resource costs of implementing any other custom solution.
Along with the control, we've applied Dynamic Dimension Security to the Cube so each user of the Site will have a dedicated connectionString to the cube with "CustomData" appended to the connectionstring. This allows us to delegate Data Segregation tasks to the Cube and BI team, and let the Web Developers concentrate on the display of the controls.
The solution is working quite well, and doesn't involve heavy weight applications like Sharepoint/Excel Services. It can built directly into your site and branded as you need, providing a sales tool as well as a useful functional tool.
Can you create a limited-access user on the cube db (read-only, only for the relevant cube, etc.) and hard-code that user/password into a connection string on the app db?
I have to develop a Django webapp which can handle several customers with their own databases.
Each customer should manage their different users and groups, with associated permissions and a set of Django's apps.
I need separate databases for security and scaling reasons. Moreover, each base size may exceed 200MB. Besides these dedicated databases, I need a "common" database to store data common to every customer (and must not be replicated to every customer database).
The fact is that I don't know how to handle the multiple customers databases (and keeping Django's auth capabilities for each customer independently : user/group/perms).
I found django-constance (https://github.com/comoga/django-constance) which allow to change settings on the fly, and I have in mind to auth with a customer identifier + username ; this way I may load the right DB with the customer identifier and auth on that one with the username.
Well, this solution does not seem to me so good, and I would appreciate if anybody has a better idea or if someone has already encountered this problem and found a workaround...
I have not found similar problems on the net, and that's quite annoying because that does not seem to me as unusual...
Thanks a lot for the time spent on this.
Keep It Simple -- leverage what Apache (or nginx or whatever) offers you.
Use mod_wsgi.
Use Apache (or nginx or whatever) to split the customer's URL's from each other
/cust1/path/to/resource
/cust2/path/to/resource
If you use Apache (or nginx or whatever) to split these things up, then each top-level path element can direct the request to a specific mod_wsgi instance
Each mod_wsgi instance has it's own settings.py that has the customer's specific database credentials.
Each customer settings.py should probably start with from master_settings import * so that you can have a "for all customers" settings which is extended by each specific customer.
I have been developing an application in Access 2003 that uses SQL Server as the back end data store. Access is used only as a GUI and does not store any data. All the code in the application is written in VBA using ADO for data access.
In recent meetings the DBA that works in my organization has become increasingly concerned over the fact that the application logic controls what data is available for viewing and for update. The way I have been developing the application up until this point is to use a single database login for all access to the database. This database login is the only user allowed access to the database and all other databases users (other than DBA types) are restricted.
The DBA for this project is insisting that each user of the application have their account mapped to only those objects in the database to which they should have access. I can certainly see his concern and that is why I was hoping to ask two questions ...
Is having a single application level login to the database a bad practice? I had planned to implement a role based security model where the "access" users were given was dependent upon their application role. However, the application logic determined whether certain queries/updates were allowed to proceed.
Does anyone know of some resources (articles/books) that go over how to design an application where database access is controlled from within SQL Server and not through the application?
It is bad practice but as you have seen - that is how most applications "evolve" starting out as wide open to a few users and getting tightened down as more people (IT/DBAs) get involved.
Your DBA should be able to help out - almost all general SQL Server books have a chapter or two on users and roles and security. They will also be able to explain the nuances of the different security options and what works best in your environment.
Alot of the setup will depend on the environment and the application. For example - if all your users are on Windows (based) connections you will want to use Windows Authentication instead of SQL Authentication. If you have many various roles you will want to use SQL Server Roles. You may want to incorporate AD groups as well as roles (or instead of). Your DBA can help you make those decisions, or even make them for you, as you explain more about your application to them.
The people on SO can certainly provide our opinions as well if you post more information about the environment and application and usage.
In my opinion
Yes it is bad practice, as a user could use the credentials to access the database in another way, circumventing your applications access control and perform actions that they shouldn't be able to. If you are on a windows domain you can create a group in AD for each of the roles and assign users to the group, then apply permissions based on that group so you don't have to add new users to SQL.
If you go down the active directory route you can use an LDAP query to see what groups the user belongs to, and you can decide whether they should have access.
It'll be interesting to read the other responses on this.
You don't say what the size of your database is or the business environment, so the answer is - it depends, but the presumption would be that your DBA is correct.
In a corporate environment the primary concern is usually the data, not the application used to access it. Indeed the data will often have a longer life than the application and changing business considerations may dictate that the data is used, and potentially modified by, different sources and not just 'your' application. In this situation it makes sense to build in security at the database level because you are ensuring the integrity of the database no matter how it is accessed, now or in the future, legitimately or illegitimately.
For 'departmental' level applications, that is where access is limited to half a dozen or so users, the data is not business-critical, and there will never be a need to use the data outside the original application then application-level security tends to be more convenient and the risks are often acceptable. I have clients who sell bespoke vertical application software to small businesses using this approach and as there's no internal IT it's difficult to imagine how else one could conveniently do it without incurring high support overheads.
However one of the defining traits of a corporate as opposed to a departmental level situation is that in the former there will be a dedicated DBA and in the latter there probably won't even be dedicated IT support, so you almost certainly must view the database as a corporate asset, and hence you should follow your DBA's advice. It's more work defining the database objects and security, but the final result is you can be confident about the integrity of your database and you'll safe yourself work when the inevitable upgrade/extension comes around.
We're not a windows shop, but one of our products is going to need to optionally integrate with Active Directory - things like SSO etc.
I'd really rather not go through the rigamarole of setting up a whole server just to develop against it and then leave it hanging around for testing purposes.
Is there a simple cloud-based service where I can purchase a server running active directory for a month or two just for development purposes? I looked into Amazon EC2 but it looks like you may still need to go through a significant set up (I may be wrong on this).
Even if you find a provider that can do hosted AD, I don't know if you'll be able to avoid the setup and configuration that goes along with it. Active Directory can be configured in so many different ways that adequately testing against it really demands more than just a default, vanilla AD domain. (I've had to deal with far too many applications that made unwarranted assumptions about how Active Directory is structured, and it's infuriating. Accounts aren't always in the default "Users" container! You can have multiple domains in a forest! Sometimes the CN isn't the userid! Aargh!)
Anyway... if you really do want to host AD on a cloud service, it can be done, but it's rare, and it sounds like it's fragile. Here's a link to a discussion on the Amazon Web Services developer forum about using AD on EC2:
http://developer.amazonwebservices.com/connect/message.jspa?messageID=150845
The document provided by garysu22 looks particularly useful, but it's also 25 pages of tweaks and workarounds... so again, lots of setup and configuration.
By the way, I'm concerned that Amazon's whitepaper on hosting AD on EC2, which used to be here...
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2435
...seems to have gone missing. I'm not sure what that means, but it would make me nervous.
(EDIT: I'm not the only one: http://justinbrodley.com/?p=60)
Now for an answer to a question you didn't ask...
I've developed against Active Directory very successfully using a local virtual machine running Windows Server and AD. I highly recommend it. You'll need a reasonably powerful machine with plenty of memory and storage, of course, but any modern development box should handle it without breaking a sweat.
With this sort of setup, you get all the niceties of a VM environment, like snapshot and rollback (so you can break stuff, even deliberately, and fix it quickly) and easy network isolation (you can make the VM visible to just the host dev box, for example)... and you can make the entire thing go away when you don't need it by just suspending the VM.
Of course, you'll still have to go through the initial AD setup and configuration, but for the kind of AD setup(s) you'll need, that's pretty easy. If you're going to be doing any serious development against AD, that's valuable experience you'll want to have anyway. Active Directory is its own sort of beast, with more than its fair share of idiosyncrasies; the better you understand it, the happier your customers will be.
Good luck!
I think you want AD Lightweight Directory Service. You can run it on any server without going through the whole AD setup/hardening process. You won't be able to use all of the AD tools against it (Users and Computers, and Trusts MMC plugins), but it will behave like AD for prototyping and development. If you see posts about ADAM (Active Directory Application Mode), AS LDS is just the latest name of the same idea.