There is already a webpart for this but it shows subsites etc, which is not the requirement.

What I need is a webpart that will list the Site collections a target user is a member of, and it must be robust enough to work with groups and AD.

I tried to check permissions however on closed site collections that the user who is viewing the list is not a member of won't show.

What I need is a way of making this transparent, so that any user can see another users site collections.

Any more ideas? I have tried several, and they either run into permissions issues or are too heavy in processing to be viable.

[update]
This is more of a challenge now than a NEED, best slickest answer gets the goodies.

[update 1]
This solution needs to be robust enough to check for a specific permission, this is due to certain sites in some collections are blocked, but some are set to read, this is done with groups, and there are open and closed site collections, which means the users get read access tot he root collection but cannot access higher ones, and sometimes are blocked totally.

The issue with this was that a user requirement was to simplify the view for permissions with users and to only show 3 custom groups, meaning we had to recode the a mass quantity of built in web parts and replace them with custom ones, also limiting views.

With this in mind, a user is given a certain group access in a site collection to be able to have a different level, by default they all get "Non Member" with gradually higher permission types. Default built in groups are not used in this installation so RunWithElevatedPriviliges was not used and we used impersonation to an AD user we created to do the same thing, different site collection types have different setups and this allows us to modify the granularity of the situation. (End users are a pain when they want to break out of the box.)

This is a 100% customised deployment and everything works perfectly, except the site collection membership display is slow with the current method, and I want to make it better!

+1 I like this a lot. Let SharePoint Search do the heavy lifting with permissions and your webpart will display instantly. I think this is about as close to realtime as you can get while still being scalable.
–
Kit MenkeSep 28 '12 at 16:23

This is the sort of solution I was looking to get for this, I like it, much more elegant and better for leveraging the built in resources we already have. +1 accepted answer and bounty awarded.
–
Hugh WoodSep 30 '12 at 17:29

The answer often varies by scale. In the small you could do this e.g. in the code-behind of a web part. However, this won't scale because what we are trying to do has exponential complexity. Perhaps you are already running into this.

The usual approaches apply for making something like this work at scale. It is often necessary to store the information (e.g. in SQL Server) as opposed to querying for it each time. Typically this involves [1] a full crawl or equivalent process for getting all of the info (when necessary) into SQL Server and [2] relying on e.g. web-scoped event handlers for keeping the stored info up to date incrementally.

A number of commercial products take this approach. Then, our web part simply queries (and perhaps caches in memory) the relevant stored information from SQL Server to meet its immediate rendering needs.

This may seem like overkill because we are almost creating a subsystem instead of a web part. However, the SharePoint object model does not give us many options because opening up an SPSite is a relatively expensive (in both time and space) operation.

I do agree with this one and I gave you a +1, but I am really excited to see if someone has a way of doing this with low overheads, I don't think there is but 50 points if there is, it will solve more than just this problem for code solutions.
–
Hugh WoodSep 26 '12 at 8:54

It would be difficult to achieve this using a webpart, as you would need to enumerate all sites in a site collections, in all webapps, in the farm. I think its better to build a Powershell utility, to do this job.

Sorry this solution just won't cut it for the environment, the company who's servers don't like this sort of approach, and like things to be encapsulated a bit more. I need something slicker and run in page preferably but efficiently.
–
Hugh WoodSep 24 '12 at 10:24