Hi Pierre! I understand your dilemma perfectly well.
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ???
Essencialy, yeah, MediaWiki sucks for the situations where you have sensitive data stored on your pages and possible attackers.
And no money for paid wikis (Confluence and cie).
Well that's weird. You've described that the wiki will be used in such a big scale... it seems to be pretty important project to spend several thousand bucks (=salary of 1-3 employees for month) on it and buy the TWiki or Confluence license.
For MediaWiki I can recommend IntraACL as well, but you have to be sure that there is no potential attackers in your case. ----- Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 3:59 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ??? I can't say to our management: "hey ! pay for a developer to patch Lockdown and the core...and in a couple of months/years, the hole system may fail after an upgrade of MW..." (caricature). :-)
The context: 1- many customers: for each customers, we have many teams to support them. Each of these teams needs a "secure space" for its documents. 2- of course, all these teams (dedicated to different customers) share some general documents. We don't need or want to secure everything: a lot of stuff can be shared by everyone.
Here is the design we try to explore actually: 1- create a shared wiki (in our office) 2- create a single wiki, on the network of a customer (so if 100 customers, it means 100 wikis: one per customer, each one on the customer network)
As it doesn't make sense for us that an employee of customer X visits the shared wiki to have access to general documents, then visits its own wiki (on the customer network) to access restricted stuff, we though to put in place a system where the admin of the customer wiki access the shared wiki and pulls some interesting info from the shared to the customer wiki. It has its limits... just a possibility...
So let's say it's a good idea... it means that the customer wiki will be accessible by all our employees dedicated to this customer... but in this wiki, there are many documents too, that we need to secure too. So:
1- Shared Wiki: (accessible by all admin of customer wikis, these admin pull info from it to put general stuff in their own wiki) 2- Customers Wikis (accessible by our people, located on the customers facilities) 3- Customers Wikis: accessible by each of our employees, dedicated to this customers. So if Jack and Daniel work for CompanyA, it means that both will log into the CompanyA wiki. 4- Customers Wikis: Jack and Daniel have different roles. Jack is a computer technician and must have access to general software procedures. Daniel works with servers and is specialized in the firewall configuration of this customer... Jack should not see the stuff of Daniel, right ? We believe that this info is sensitive... So it means that we need to secure some namespace (for example) to prevent Jack to access Daniel stuff... So LockDown extension ? 5- Security: here, if MW with Lockdown fails, it will be a failure which will stay on the customer network (damage is limited, but absolutely not desirable!!!). That's one of the reason we prefer to separate general stuff (shared wiki) from the customer wiki (sensitive): isolation of the failure. If we put Lockdown on a single wiki, shared by all, and that a failure occurs: it means that every customer may be able to access the data of everyone else (firewall config for example...).
That's where we are for now... Yes: Dokuwiki, MoinMoin, etc... have ACL and are cerftainly the best choice for medium size wikis. But what's append with these wiki engines when you have 200/300/400 000 - 1 000 000 pages ? Are they seriously designed to support all these pages/images/doc, etc ? The search feature will become slow ? etc... we don't know... And no money for paid wikis (Confluence and cie).
What else: there are a tons of wiki engines. Why we prefer to have Mediawiki ? Well... to be honest... it's Mediawiki :-)
I sincerely hope that my English is clear... :-)
Cheers !
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Friday, August 23, 2013 6:32 PM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
I guess that one option for you will be to hire somebody or some company for developing Lockdown further so that they can cover all the holes from which the information can bet got. HalloWelt itself is a perfect candidate and we also have a lot more developers available [1]. Probably you will also want to hire different contractor that will try to steal the data from the modified extension.
Of course, after some time the extension will stop working because of ugly hacks that will definetely appear in the code.
Another and more proper solution is not so fast, that is: to lobby the proper ACL support in MediaWiki core before starting development. MediaWiki is used as an enterprise wiki and the impossibility of good ACL should not be considered as not some kind of philosophy of the software (as some people claims) but as a bug that needs fixing. Still even in this case the actual development of ACL won't be done by WMF - they aren't just interested in it. But if we would have carte blanche for patching the core and not been declined because "MW is an Open System, it has not been Designed to allow ACL support", I think many parties will be interested to fund the development.
[1] www.mediawiki.org/wiki/Professional_development_and_consulting
Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 1:36 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups… We don’t want to go with many tons of wikis installation…
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but it’s after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
NamespaceA (read for departmentA only)NamespaceB (read for departmentB only)….NamespaceZ (read for departmentZ)Sometimes, someone of departmentA will need read access to NamespaceZ, etc…
I would like to have some testimonials: your experiences, your recommendations… on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe…).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-qu estion-of-features/ and found that they use Lockdown and some other extensions around it, to secure the wiki
As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_exten sions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_exten sions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki… I didn’t insist to know which other tool… I was impressed that a guy at this level take the time to answer me, so… J
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc… Wikifarm ? etc…
Sincerely, I believe I have read enough on the web about the subject… now, I need some concrete experiences, from real persons, in real enterprises,…
Voilà.
Thanks !
Pierre
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise