We are trying to create a SaS based portal using Liferay 6 for multiple (non related) organizations. And we want to go for a approach where we can generate these organization setup automatically based on user information.
We may require to have separate domains/websites for each organization.
As of now I have thought about two options for this
Portal Instance
Organizations
As per my understanding, i think this can be achieved by both of the above approaches. I would like to know your experience on both of these approaches on following points.
Which one would be easy to administer in long run
Which one can be easily programmed to create new setup automatically.
What about data security related to keeping in one portal instance vs multiple instance (is there any such thing?? not sure)
Any other approach to this?
Simple answer would be Portal Instances, since it was built for multi-tenancy.
Benefits to this approach would be that there would be segregation of data. Each instance maintains its own collection of users, communities, blog entries, etc.
Administration wise, there will be 1 account, the omni-admin, that can access all of these instances. On top that, each instance could have its own administrator that admins that particular instance.
Also, I don't believe using organizations will allow you to have separate domains for them.
Also going forward in Liferay 6.1, Organizations don't have pages only Sites have them, though we can mimic the behaviour with Sites.
Hope this helps.
I'm using Organizations for multiple sites, none of them sees each other, each one have their own users, roles, sections and communities.
Apache and Liferay virtual hosts url's makes the proper redirects to each organization home page.
For the admin I think is easier because in one control panel you can manage everything, or just the "scope" you want.
About using Instances, check the procedure to configurate them and see if you find it possible to create new ones automatically. Not very sure about that for organizations either, but having to touch portal-ext.properties may be worse towards automatization.
Regards
Related
We have a suite of apps we are developing. We have already rolled the app out to about 50 users and have over 200 more. Sharing connections (custom connection & connector) and the apps have become super cumbersome. Long story short, this is a lot of time. Each time we have a new user we have to share 3 apps, 2x connections, and setup access on an internal method we have. We are using SQL, not CDS.
This has been misery. Is there a way to create 1x address that I would share with the Apps/Connection and I would just add users to this group? Would save us time to just add users to the one list. Then access is just shared via this common group. Does anyone know a better method to deploy powerapps like this? We can't share to "everyone". Thanks.
If you have an Azure Active Directory Security Group you can give them access to the connector and powerapp. See: https://powerapps.microsoft.com/en-us/blog/sharing-powerapps-with-multiple-users/
There are some kind of distinctions between Security Groups, Distribution Groups, O365 groups, and on prem vs Azure. I couldn't tell you the difference between them all, but you can follow Microsoft's instructions on how to share a canvas app which will go through some of these different methods of sharing.
I have 2 web roles. Each maintains a Concurrent Dictionary which it updates. Is there a way to make sure that changes made by one is visible to others.
Or in other words, for N number of web role instances there should be only 1 copy of data (Collection or Object not DB Table).
Each instance of a web role is a separate VM. So... whatever technique you'd use between two computers would be viable with two VMs.
You mentioned no databases, so that rules out quite a bit. You simply cannot share collections or objects because, again, you're talking about synchronization across two completely separate VMs.
Note that Cloud Services have a Cache Role as well, which you can consider for sharing content between your instances (and this is certainly not the ultimate answer; I'm simply pointing out what Cloud Services provide out-of-the-box).
I need to build an application that manages users and I thought that it will be nice to follow an existing management model, like the one used by Windows or linux, that has users, groups, permissions etc.
I couldn't find any place on the Internet to get explanations about how to implement this.
My application is a web application, probably asp.Net (less important the technology) that manages users. I have few levels, for now system administrators, power users, group managers and simple users.
Each level offers privileges, like power users may see all the users, may promote a user to be up to group manager, may degrade a user (with less powers than his) etc.
There is any place where I can read about how to implement such system?
Probably using the ASP.NET membership provider will work for you. You can use the SqlMembershipProvider which stores the security information in a Sql Server database. If you need more advanced features (and probably more secure), you can use Active Directory or ADAM with the ActiveDirectoryMembershipProvider. The ASP.NET membership provider model is customizable and you can implement your own provider, but the existing ones are quite powerful.
1) I need help in setting up the liferay portal instance with multiple domains.
I have one portal instance with multiple organizations ( for example: abc org, xyz org, etc)
I want to map these organizations to different domains (for example: abc.com, xyz.com, etc)
I know that multiple portal instances with different company name (different companyId's) can be mapped through admin login in liferay,
BUT
need help with the above mentioned setup: one instance-multiple org-mapped to multiple domains
2) If I use multiple instances, will this make performance issue in liferay?
Considering if we go with 1000 organizations with their respective domains mapped.
1st question, checkout Virtual Hosting on Liferay's web site.
2nd question, from my points of view, running 1000 micro websites on a single portal instances will definitely hit performance.
We created a custom Liferay application that enables a company to sell products to customers. These customers also have access to whatever they bought via Liferay. A customer can have multiple users that access the portal through this customer account. So we tried adding an organization in Liferay for each customer, but this soon proved to be a very big performance hit. Liferay is able to handle 10's and maybe 100's of organizations, but 1000's and 10000's is too much. So I guess you'll possibly need multiple Liferay servers to handle 1000 mini-sites.
I want to set up TFS permissions to better reflect the responsibilities and levels of clearance of different roles within my organization; I'm finding that the default Reader and Contributor groups are too coarse-grained for my needs (and too loosely named).
To keep maintenance overheads to a minimum, I'm therefore thinking of replacing the Contributor and Reader groups with my own groups, but... is there any negative side effect of deleting those two groups? Does any part of TFS rely on them being there?
You should be fine. The built-in groups at the project level are for convenience only.
(This is NOT true of some of the server-level groups like TF Valid Users and TF Licensed Users. Maybe TF Service Accounts as well, I forget. These "well known groups" play a specific role in internal TFS operations. Delete them and the system won't work, even if you recreate them exactly as they were, because the GUIDs won't match.)
Just make sure that if you remove the Project Administrators group, you still have admin privileges inheriting from another group (eg TF Admins), otherwise you'll find yourself in a catch-22 situation. If you do get stuck by accident, know that local admins on the application tier machine are "TFS super-admins" who can bypass all security checks and put things back in order.
-EDIT-
One thing you will have to do is manually grant permissions to the new groups in Sharepoint and Reporting Services. I'd recommend downloading the TFS Admin Tool -- makes these tasks much simpler.