Options / strategies for implementing subportals

Question

I am currently working to create a "subportal" for a specifically intended only for a subset of our portal users. I am trying to determine if creating a different URL for the subportal would be better or simply base the experience definition on which community the users are currently in.
Separate URL:
Pros:
1) I know how to show a different branded login page based on URL. I have no idea how to show the non-default login page otherwise. Is it possible?
2) Users can perform searches using the default search AS and still have the subportal branding
3) users can view other users profile pages with subportal branding.
Cons:
1) What happens if a user logs in to subportal1 but then clicks on a link to a community that is supposed to be in subportal2. I would suspect that they would see the community with the wrong header.
2) Users would have to relogin when moving between portal base urls (www.myportal.com/portal/sever.pt and subportal.myportal.com/portal/server.pt, for example). Probably possible to get around this using cookie domains.
3) Because there are really 2 different UI's of the same site, nothing will prevent a user from accessing a user's profile from the subportal URL when that user isn't part of the group that the subportal belongs to.
4) What happens if a user that doens't have access to the subportal tries to login using the subportal URL?
Same URL, base experience rule on current community
Pros:
1) Switching between communites in different subportals will switch experiences, which is probably desired.
2) Easier to explain to users that they are still on the same "site", so you can do things like "search this subportal, search all subportals" with less confusion.
Cons:
1) Hard (impossible?) to keep Search AS / User Profile AS separate?
2) How to show separate login page?
I guess a third option would be to use separate portal databases... but i was hoping to avoid that.
What does your company do to handle this?
Thanks!
Edited by: Joel Collins on Dec 17, 2008 6:48 AM

Answer 1

Ah ha! You've uncovered the truth about subportals -- that they're not really subportals at all. (That could explain why they were renamed to Experience Definitions.)
It's hard to tell exactly what you're trying to accomplish from your post, but if you're trying to secure access to content, the safest (though also most expensive) way to do that is with a separate portal database. As you've discovered, setting up an experience definition, whether you use a separate URL or not, does not affect portal security at all.
Let me address some of your points below (your text in italics):
+1) I know how to show a different branded login page based on URL. I have no idea how to show the non-default login page otherwise. Is it possible?+
Yes. You can use source IP address or address range. Don't know if that will work for you, but I thought it was worth mentioning. There are probably other ways too, but I don't have the screen in front of me with the complete list. The screen to which I'm referring is the experience definition rules manager, I think.
+2) Users can perform searches using the default search AS and still have the subportal branding+
True, but you don't need a separate URL for this. If you base the branding on the experience definition (subportal) rather than on the community, and base the subportal "assignment" (for lack of a better term) on, say, what folder the user is in, you'll still get a correctly branded search activity space.
+3) users can view other users profile pages with subportal branding.+
My comment about #2 also applies here.
+1) What happens if a user logs in to subportal1 but then clicks on a link to a community that is supposed to be in subportal2. I would suspect that they would see the community with the wrong header.+
They will see the community with subportal1's header, unless there is some other rule that kicks in to change that behavior OR if you've applied branding at the community level. Community-level branding wins over subportal-level branding.
+2) Users would have to relogin when moving between portal base urls (www.myportal.com/portal/sever.pt and subportal.myportal.com/portal/server.pt, for example). Probably possible to get around this using cookie domains.+
Correct and correct. Of course the only reason they would ever change URLs is if they clicked an absolute link somewhere or typed in the other address. Most, if not all, of the links in the portal should resolve as relative links, keeping users in the same subdomain.
+3) Because there are really 2 different UI's of the same site, nothing will prevent a user from accessing a user's profile from the subportal URL when that user isn't part of the group that the subportal belongs to.+
That's correct -- and, as I'm sure you know by now, seems to contradict the meaning of the word "subportal." This is a common misconception -- that subportals have something to do with security -- but I see you've already figured that out. :-)
+4) What happens if a user that doesn't have access to the subportal tries to login using the subportal URL?+
Interesting question. I've never tried, but my assumption would be that the portal would throw an error, kind of like when you try to open a web service when you don't have access to the remote server (I think). There are lots of parent-child relationship things in the portal that can get fouled up. As you know from #3, setting security on the experience definition won't really do anything (except prevent people from editing it and perhaps cause weird errors). Applying portal security to communities, portlets, documents, etc. is the way people secure their portals. That was true before subportals existed and it's still true now, as experience definitions have no effect upon security.
+1) Switching between communites in different subportals will switch experiences, which is probably desired.+
Correct.
+2) Easier to explain to users that they are still on the same "site", so you can do things like "search this subportal, search all subportals" with less confusion.+
Correct.
+1) Hard (impossible?) to keep Search AS / User Profile AS separate?+
By separate, what do you mean? Let me explain . . . if my experience definition is based on what community I'm in, when I leave that community, my experience definition is, by definition :-), undefined. You can probably hack the native code to make the activity spaces for search and user profile do something crazy, like maintain the experience definition of the last community you visited, but I'm not sure you'd want to go there technically nor do I know if that's the best experience for your users or not.
+2) How to show separate login page?+
See #1, uh, the first #1.
I hope this helps (at least a little bit). Experience definitions are very confusing and, as I mentioned, I'm not 100% sure what your use case is. If you care to describe that in more detail, I might be able to help out a bit more.