Hi Luis, My company is also an ASP and I have built (and am continually building) a single portal to service all of our customers, only I am using Jetspeed 2 (which would be my recommendation).
I wish I could tell you that J2 could do this kind of data segmentation out of the box, but AFAIK, there is no way to do it. We have similar requirements as you do. For example, we allow our customers to manage their own users. I'm going to describe to you in general what we've done and you can decide if a similar setup is right for you. Firstly, to make things easy, I don't allow any one to edit pages. I basically author the pages and deploy them in order to expose the functionality I want. The reason for this is to make sure that users can't add administrative portlets to their pages. I think maybe since 2.0, there may be access control for portlets, but am not sure (I have implemented my own access control mechanism in a base class that all my portlets extend). Secondly, I have divided my user base into groups according to the customer accounts (ie. a customer account is a group). This allows me to profile users according to which organization the user belongs to (ie. can have a specific skin or specific functionality in special cases). Additionally, each user is assigned roles which controls what functionality (portlets) each user has access to. Finally, I have implemented my own custom user management portlet so that I can: -add whatever custom attributes I need to for a given user -enforce that every user must be a member of some customer group (or internal group) -enforce that only internal users can have internal roles -and most importantly, segmentation of the data The segmentation of the data is what you are really after here. Basically, my user management portlet checks the profile of the logged in user. If they are internal, they can access all users. Otherwise, they can only access (view,add,edit) user accounts that belong to the same customer organization. I actually made a base "Data Management Portlet" that solves the problem for us in general, since we have a bunch of different data that has to remain segmented in the same way. One other thing: we use an LDAP directory to store our users, groups and roles (although you can use a DB and achieve the same results). But the point here is that I am not using the J2 user/role/group tables at all and I have implemented my own ATN/ATZ components. Not that I am saying you need to do this necessarily, but in our case, it just made things simpler in the long run since we want to use the user database for ATN/ATZ for other systems, and ultimately, for an enterprise SSO solution. Anyhow, I hope all of this helps you. -aaron On 11/1/06, luiscolorado <[EMAIL PROTECTED]> wrote:
Hi! We are an Application Server Provider, who have about 30 customers. Each customer may have about 30 users, so we have about 1,000 users. We want to deploy a portal for our customers using jetspeed-1. I want to allow customers, let say company A, administer their own users. However, I don't want that company A can see the users of company B. I think I could achieve this by deploying multiple instances of the portal, that is, deploy one new portal for each company... I would have about 30 portals. I think that is pretty ugly... what if I want to deploy a new portlet to all the 30 customers? I would have to deploy it to 30 different directories. What if we grow to have 100 customers? If that's they it has to be done, fine, but I don't know if that's the best way to do it. Have you ever done something like that before? What is a good approach to host multiple portals? Thank you all! Luis -- View this message in context: http://www.nabble.com/Hosting-multiple-portals-tf2555125.html#a7120064 Sent from the Jetspeed - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
