Hello,
(sorry for my poor English.)
This is probably a recurring question.
I work for an IT company of around 80 000 employees and we would like to build an enterprise wiki, where we will put all our technical documentation (how to, troubleshooting, scripting, etc.).
80 000 employees, but this wiki will be for 1000 of them. It may generate a minimum of 200 000/300 000 pages + images + etc.
You have to know that in some of our documentation, we have usernames and passwords, or maybe firewall configuration, etc. for different customers.
Of course, I know that Mediawiki cannot provide a per page/category security (at a read level): my understanding is that Mediawiki is "Read all pages" or "Access denied to all pages". nothing in between. So we cannot restrict view of some documents to a specific group.
Fine.
So let's say that it's not a problem and that all our technicians will be able to read all the technical documents, of all our customers.
Someone told me that we just don't have to put some confidential informations in our wiki documents (no user/password/confidential config/etc.).
Fine. But where ? If we don't put them in the wiki pages, it means that the users will have to go in the wiki for the basic informations, then go on another tool to have the confidential info.
Now, my question: how do you manage this ?
I really love Mediawiki and would like to implement it in our business, but I haven't enough information on how this can be implemented in the reality of a business.
And no: no budget to buy something like Confluence.
I have try Dokuwiki, XWiki, Tiki, MoinMoin, many others. I love Dokuwiki too, but wasn't sure enough it was a strong tool to be able to manage that amount of pages/images/. Anyway, I always come back to MediaWiki. I don't know why.
Best regards,
Pierre
There is some access control possibility, by giving certain namespaces or articles specific group requirements to view. Only grant privileged users those groups needed to read or edit the secure docs.
Alternatively, create two parallel wikis, one of which is open internal access having the non-secure information, and then a secure wiki with the passwords and so forth (only); interwiki links can be made fairly easily. Only grant the users in the support teams who need access to customer systems logins on the second wiki, track its access more closely, etc.
Or, alternately, don't try and do that last role in Mediawiki, but instead set up an enterprise password management system, and have the Wiki link to that for users who might need those. Rather than having "document management" of those passwords, put them in the password manager, and have it and its access controls handle all the access to them.
The latter - avoiding all 'plain document' storage of passwords - will meet the more stringent enterprise security concerns. Linking to arbitrary URLs for the password manager is fine, all the products I know of are web interface (https) and can have an entry URL specific to the thing you were looking to try and check out and use.
Depending on how sensitive the info is, I might do three tiers; Tier 1, a standard MediaWiki with open access, generic non-secure documents. Tier 2, a second MediaWiki installation, with secure individual tech-only logins required, with "confidential configuration documents" and the like. Tier 3, an enterprise password manager for managing individual admins' checkouts of passwords for use on customer systems on an as-needed basis with all that logging and control.
On Fri, Aug 9, 2013 at 8:10 PM, Pierre Labrecque pierre.labrecque@live.cawrote:
Hello,
(sorry for my poor English.)
This is probably a recurring question.
I work for an IT company of around 80 000 employees and we would like to build an enterprise wiki, where we will put all our technical documentation (how to, troubleshooting, scripting, etc.).
80 000 employees, but this wiki will be for 1000 of them. It may generate a minimum of 200 000/300 000 pages + images + etc.
You have to know that in some of our documentation, we have usernames and passwords, or maybe firewall configuration, etc. for different customers.
Of course, I know that Mediawiki cannot provide a per page/category security (at a read level): my understanding is that Mediawiki is "Read all pages" or "Access denied to all pages". nothing in between. So we cannot restrict view of some documents to a specific group.
Fine.
So let's say that it's not a problem and that all our technicians will be able to read all the technical documents, of all our customers.
Someone told me that we just don't have to put some confidential informations in our wiki documents (no user/password/confidential config/etc.).
Fine. But where ? If we don't put them in the wiki pages, it means that the users will have to go in the wiki for the basic informations, then go on another tool to have the confidential info.
Now, my question: how do you manage this ?
I really love Mediawiki and would like to implement it in our business, but I haven't enough information on how this can be implemented in the reality of a business.
And no: no budget to buy something like Confluence.
I have try Dokuwiki, XWiki, Tiki, MoinMoin, many others. I love Dokuwiki too, but wasn't sure enough it was a strong tool to be able to manage that amount of pages/images/. Anyway, I always come back to MediaWiki. I don't know why.
Best regards,
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I'm not sure how much help this is, but it should be possible to "section off" certain levels of the wiki for certain user groups (you could possibly make a "user group" for every individual user if you needed to)
What you would do, for sections with info so sensitive that only one or two people should have access is simply to restrict everything, even the ability to read the page (including the page source) in any way, to just those user groups you specify. This would effectively secure that information to just those parties alone, though this would require manually toggling settings for each user group, which would be extremely tedious yet doable.
That security hassle aside, MediaWiki is probably the best option you have for handling such a large amount of content, and while I'm no expert on wiki security, it is probably the most well featured wiki when it comes to additional security options and extensions you can install and configure, and I would highly recommend using it.
In fact, I found an extension that should serve your security needs well in blocking even page sources from being viewable (for your needs, this would be essential)
https://www.mediawiki.org/wiki/Extension:ProtectSource
You also want this extension, just to close loopholes in the above extension, such as the Special:Import/Export special pages:
https://www.mediawiki.org/wiki/Extension:DisableSpecialPages
I'm not sure what else you need at the moment, but you should check out all the page permission and security extensions on MediaWiki.org, not to mention all the page permission documentation available to determine how feasible the level of security you desire is:
https://www.mediawiki.org/wiki/Permissions
Hope that helps.
From: pierre.labrecque@live.ca To: mediawiki-l@lists.wikimedia.org Date: Fri, 9 Aug 2013 23:10:05 -0400 Subject: [MediaWiki-l] Mediawiki as an Enterprise wiki
Hello,
(sorry for my poor English.)
This is probably a recurring question.
I work for an IT company of around 80 000 employees and we would like to build an enterprise wiki, where we will put all our technical documentation (how to, troubleshooting, scripting, etc.).
80 000 employees, but this wiki will be for 1000 of them. It may generate a minimum of 200 000/300 000 pages + images + etc.
You have to know that in some of our documentation, we have usernames and passwords, or maybe firewall configuration, etc. for different customers.
Of course, I know that Mediawiki cannot provide a per page/category security (at a read level): my understanding is that Mediawiki is "Read all pages" or "Access denied to all pages". nothing in between. So we cannot restrict view of some documents to a specific group.
Fine.
So let's say that it's not a problem and that all our technicians will be able to read all the technical documents, of all our customers.
Someone told me that we just don't have to put some confidential informations in our wiki documents (no user/password/confidential config/etc.).
Fine. But where ? If we don't put them in the wiki pages, it means that the users will have to go in the wiki for the basic informations, then go on another tool to have the confidential info.
Now, my question: how do you manage this ?
I really love Mediawiki and would like to implement it in our business, but I haven't enough information on how this can be implemented in the reality of a business.
And no: no budget to buy something like Confluence.
I have try Dokuwiki, XWiki, Tiki, MoinMoin, many others. I love Dokuwiki too, but wasn't sure enough it was a strong tool to be able to manage that amount of pages/images/. Anyway, I always come back to MediaWiki. I don't know why.
Best regards,
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hello,
I read all the answers and I thank you all. I finally do a test with the LockDown extension ( https://www.mediawiki.org/wiki/Extension:Lockdown ) on our Mediawiki 1.21.1 installation, and it seems to work fine. Of course, I cannot say if it's really secure or if we will have to implement some other extensions on top of it, but it seems to work as is...
Another question: do you use LockDown ? If it doesn't prevent to list a page when we do a search, it prevent to display the page itself, which is OK for us. Is there other limitations ?
What we can do: 1- create a page "FOO1:Procedure To do this" and give general informations on it, accessible to all users... and on "FOO1:Procedure to do this" we put a link to "FOO2:SecretPasswords" 2- if the user needs the passwords, he clicks on "FOO2:SecretPasswords". If he has access to the FOO2 namespace (as defined in the LockDown parameters, in LocalSettings), all is ok for him and he has access to the page. If he doesn't, then he receives an access denied. Make sens for you ?
Thanks again for all you comments !
(I sincerely hope that my English is clear enough :-) ) Pierre
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Arcane 21 Sent: Friday, August 09, 2013 11:49 PM To: mediawiki-l@lists.wikimedia.org Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
I'm not sure how much help this is, but it should be possible to "section off" certain levels of the wiki for certain user groups (you could possibly make a "user group" for every individual user if you needed to)
What you would do, for sections with info so sensitive that only one or two people should have access is simply to restrict everything, even the ability to read the page (including the page source) in any way, to just those user groups you specify. This would effectively secure that information to just those parties alone, though this would require manually toggling settings for each user group, which would be extremely tedious yet doable.
That security hassle aside, MediaWiki is probably the best option you have for handling such a large amount of content, and while I'm no expert on wiki security, it is probably the most well featured wiki when it comes to additional security options and extensions you can install and configure, and I would highly recommend using it.
In fact, I found an extension that should serve your security needs well in blocking even page sources from being viewable (for your needs, this would be essential)
https://www.mediawiki.org/wiki/Extension:ProtectSource
You also want this extension, just to close loopholes in the above extension, such as the Special:Import/Export special pages:
https://www.mediawiki.org/wiki/Extension:DisableSpecialPages
I'm not sure what else you need at the moment, but you should check out all the page permission and security extensions on MediaWiki.org, not to mention all the page permission documentation available to determine how feasible the level of security you desire is:
https://www.mediawiki.org/wiki/Permissions
Hope that helps.
From: pierre.labrecque@live.ca To: mediawiki-l@lists.wikimedia.org Date: Fri, 9 Aug 2013 23:10:05 -0400 Subject: [MediaWiki-l] Mediawiki as an Enterprise wiki
Hello,
(sorry for my poor English.)
This is probably a recurring question.
I work for an IT company of around 80 000 employees and we would like to build an enterprise wiki, where we will put all our technical documentation (how to, troubleshooting, scripting, etc.).
80 000 employees, but this wiki will be for 1000 of them. It may generate a minimum of 200 000/300 000 pages + images + etc.
You have to know that in some of our documentation, we have usernames and passwords, or maybe firewall configuration, etc. for different customers.
Of course, I know that Mediawiki cannot provide a per page/category security (at a read level): my understanding is that Mediawiki is "Read all pages" or "Access denied to all pages". nothing in between. So we cannot restrict view of some documents to a specific group.
Fine.
So let's say that it's not a problem and that all our technicians will be able to read all the technical documents, of all our customers.
Someone told me that we just don't have to put some confidential informations in our wiki documents (no user/password/confidential config/etc.).
Fine. But where ? If we don't put them in the wiki pages, it means that the users will have to go in the wiki for the basic informations, then go on another tool to have the confidential info.
Now, my question: how do you manage this ?
I really love Mediawiki and would like to implement it in our business, but I haven't enough information on how this can be implemented in the reality of a business.
And no: no budget to buy something like Confluence.
I have try Dokuwiki, XWiki, Tiki, MoinMoin, many others. I love Dokuwiki too, but wasn't sure enough it was a strong tool to be able to manage that amount of pages/images/. Anyway, I always come back to MediaWiki. I don't know why.
Best regards,
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Sat, Aug 10, 2013 at 4:15 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
1- create a page "FOO1:Procedure To do this" and give general informations on it, accessible to all users... and on "FOO1:Procedure to do this" we put a link to "FOO2:SecretPasswords" 2- if the user needs the passwords, he clicks on "FOO2:SecretPasswords". If he has access to the FOO2 namespace (as defined in the LockDown parameters, in LocalSettings), all is ok for him and he has access to the page. If he doesn't, then he receives an access denied. Make sens for you ?
bottom line is most (all?) of these security extensions (e.g. LockDown) have either not had WMF security review or have not passed. the known good, very effective and secure way to do this is 2 separate wikis with interwiki links between them. (and different sets of people can log in to each one) The WMF config for private fishbowls is published so you can copy from there. ( https://noc.wikimedia.org/conf/ https://git.wikimedia.org/summary/?r=operations/mediawiki-config.git ; `git grep` is your friend! ) You should make sure that the wikis are on different domains and cookies set by either wiki are not accessible by the other one.
You could have exactly the same setup described above (which I quoted) using 2 separate wikis. FOO1 and FOO2 are different wikis. FOO2 at FOO1 is not a namespace but rather is an interwiki link.
-Jeremy
I have to explain a little bit more our situation... We have documents for:
1 - General documents (I will call them DOC_A) 2- More sensitive documents (I will call them DOC_B)
For DOC_A, well, no problem: each user of the wiki can read them.
For DOC_B: we have several "sub-categories", where each sub-category is one of our customers and where each one must be read only by the IT technicians (TECH_x) who are supporting this customer. This means that TECH_A will be able to read DOC_A and only one category under DOC_B, that TECH_B will be able to read DOC_A and another category under DOC_B) So in fact, we have:
1.0 DOC_A (read for all users) 2.0 DOC_B 2.1 DOC_B_CUSTOMER_1 (read by TECH_A) 2.2 DOC_B_CUSTOMER_2 (read by TECH_B) 2.3 DOC_B_CUSTOMER_3 (read by TECH_C) 2.4 DOC_B_CUSTOMER_4 (read by TECH_D) 2.5 DOC_B_CUSTOMER_5 (read by TECH_E) 2.6 DOC_B_CUSTOMER_6 (read by TECH_F) 2.7 DOC_B_CUSTOMER_7 (read by TECH_G) Etc... T ons of customers... : 1- so tons of wikis ??? 2- if multiple wikis, this implies also that one of our tech who work for CUSTOMER_1, 2 and 5, will have to log in several wikis to have a couple of informations on each ones ? Lost time, no ? Even with a shared user database, our tech will have to do multiple login ?
That's why I tested LockDown, after reading these 2 pages (and trying to understand... I'm a newbie in all this...): https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions https://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions
Well... it seems that I'm not too bad in English :-)
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jeremy Baron Sent: Saturday, August 10, 2013 1:48 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
On Sat, Aug 10, 2013 at 4:15 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
1- create a page "FOO1:Procedure To do this" and give general informations on it, accessible to all users... and on "FOO1:Procedure to do this" we put a link to "FOO2:SecretPasswords" 2- if the user needs the passwords, he clicks on "FOO2:SecretPasswords". If he has access to the FOO2 namespace (as defined in the LockDown parameters, in LocalSettings), all is ok for him and he has access to the page. If he doesn't, then he receives an access denied. Make sens for you ?
bottom line is most (all?) of these security extensions (e.g. LockDown) have either not had WMF security review or have not passed. the known good, very effective and secure way to do this is 2 separate wikis with interwiki links between them. (and different sets of people can log in to each one) The WMF config for private fishbowls is published so you can copy from there. ( https://noc.wikimedia.org/conf/ https://git.wikimedia.org/summary/?r=operations/mediawiki-config.git ; `git grep` is your friend! ) You should make sure that the wikis are on different domains and cookies set by either wiki are not accessible by the other one.
You could have exactly the same setup described above (which I quoted) using 2 separate wikis. FOO1 and FOO2 are different wikis. FOO2 at FOO1 is not a namespace but rather is an interwiki link.
-Jeremy
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
http://en.wikipedia.org/wiki/Access_control_list
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
By design MW is not a CMS. You need a content management system with a good ACL built in.
You are asking for too much with your example but a CMS could handle it just fine. e.g. Type 'Secret Docs' - Tech 1 could be a Company A, B, C maintainer. Tech 2 could be a Company C, D, E, F maintainer. Tech 3 could be a Company A and E maintainer. All 3 techs could also be in a Type 'Public Docs' group.
You can take it even further with Tech 3 being a read only user. So the tech could read Company A and E docs on Tech 1 can edit A and Tech 2 can edit E.
MW does have permissions but they are group based. ACL in a CMS can compare group, user, content(page), category, state(read, edit, etc.) then make sure a user has met every Access Control before proceeding.
Tom
On Aug 10, 2013, at 3:21 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
E
Yes, I understand... unfortunately, I understand :-) Last question: if all this is true (ACL side), what do you think of: http://www.blue-spice.org/ It seems they use an ACL extension as a workaround of the MW limitations, no ? Thanks again for all your comments !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tom Sent: Saturday, August 10, 2013 6:48 PM To: MediaWiki announcements and site admin list Cc: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
http://en.wikipedia.org/wiki/Access_control_list
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
By design MW is not a CMS. You need a content management system with a good ACL built in.
You are asking for too much with your example but a CMS could handle it just fine. e.g. Type 'Secret Docs' - Tech 1 could be a Company A, B, C maintainer. Tech 2 could be a Company C, D, E, F maintainer. Tech 3 could be a Company A and E maintainer. All 3 techs could also be in a Type 'Public Docs' group.
You can take it even further with Tech 3 being a read only user. So the tech could read Company A and E docs on Tech 1 can edit A and Tech 2 can edit E.
MW does have permissions but they are group based. ACL in a CMS can compare group, user, content(page), category, state(read, edit, etc.) then make sure a user has met every Access Control before proceeding.
Tom
On Aug 10, 2013, at 3:21 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
E
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
In fact there are some ACL extensions that are used by consultancies, see [1], [2]. Bluespice is probably one of the coolest MediaWiki-based enterprise system which can be used entirely or as part of your enterprise wiki. What you should always have in mind is that you don't have a guarantee that the information you've hidden is unaccessible. In other words you can use ACL extensions so that different groups of your users can see different sets of pages, but you certainly don't want to store the people credit cards numbers in a hidden pages.
[1] http://diqa-pm.com/de/Main_Page [2] https://gesinn.it/de/semantic-apps ----- Yury Katkov, WikiVote
On Sun, Aug 11, 2013 at 5:04 AM, Pierre Labrecque pierre.labrecque@live.cawrote:
Yes, I understand... unfortunately, I understand :-) Last question: if all this is true (ACL side), what do you think of: http://www.blue-spice.org/ It seems they use an ACL extension as a workaround of the MW limitations, no ? Thanks again for all your comments !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto: mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tom Sent: Saturday, August 10, 2013 6:48 PM To: MediaWiki announcements and site admin list Cc: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
http://en.wikipedia.org/wiki/Access_control_list
http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
By design MW is not a CMS. You need a content management system with a good ACL built in.
You are asking for too much with your example but a CMS could handle it just fine. e.g. Type 'Secret Docs' - Tech 1 could be a Company A, B, C maintainer. Tech 2 could be a Company C, D, E, F maintainer. Tech 3 could be a Company A and E maintainer. All 3 techs could also be in a Type 'Public Docs' group.
You can take it even further with Tech 3 being a read only user. So the tech could read Company A and E docs on Tech 1 can edit A and Tech 2 can edit E.
MW does have permissions but they are group based. ACL in a CMS can compare group, user, content(page), category, state(read, edit, etc.) then make sure a user has met every Access Control before proceeding.
Tom
On Aug 10, 2013, at 3:21 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
E
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
It seems like a well balanced response :-) So if we compare ACL extensions to Windows, we will say that it' stable, but may crash sometimes. I would like to thank you all again for all these varied comments. It really help !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Saturday, August 10, 2013 10:24 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
In fact there are some ACL extensions that are used by consultancies, see [1], [2]. Bluespice is probably one of the coolest MediaWiki-based enterprise system which can be used entirely or as part of your enterprise wiki. What you should always have in mind is that you don't have a guarantee that the information you've hidden is unaccessible. In other words you can use ACL extensions so that different groups of your users can see different sets of pages, but you certainly don't want to store the people credit cards numbers in a hidden pages.
[1] http://diqa-pm.com/de/Main_Page [2] https://gesinn.it/de/semantic-apps ----- Yury Katkov, WikiVote
On Sun, Aug 11, 2013 at 5:04 AM, Pierre Labrecque pierre.labrecque@live.cawrote:
Yes, I understand... unfortunately, I understand :-) Last question: if all this is true (ACL side), what do you think of: http://www.blue-spice.org/ It seems they use an ACL extension as a workaround of the MW limitations, no ? Thanks again for all your comments !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto: mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tom Sent: Saturday, August 10, 2013 6:48 PM To: MediaWiki announcements and site admin list Cc: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
http://en.wikipedia.org/wiki/Access_control_list
http://www.mediawiki.org/wiki/Security_issues_with_authorization_exten sions
By design MW is not a CMS. You need a content management system with a good ACL built in.
You are asking for too much with your example but a CMS could handle it just fine. e.g. Type 'Secret Docs' - Tech 1 could be a Company A, B, C maintainer. Tech 2 could be a Company C, D, E, F maintainer. Tech 3 could be a Company A and E maintainer. All 3 techs could also be in a Type 'Public Docs' group.
You can take it even further with Tech 3 being a read only user. So the tech could read Company A and E docs on Tech 1 can edit A and Tech 2 can edit E.
MW does have permissions but they are group based. ACL in a CMS can compare group, user, content(page), category, state(read, edit, etc.) then make sure a user has met every Access Control before proceeding.
Tom
On Aug 10, 2013, at 3:21 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
E
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
So if we compare ACL extensions to Windows, we will say that it' stable,
but may crash sometimes.
Well, not literally crashes. ;-)
If your goal is to hide some pages from some groups of people in order not to confuse them - well then MediaWiki has good ACL. If however your goal is to hide some info to prevent access, or if you presuppose the possible misuse or malicious users or want to store confidential information - well, sorry: I can retrieve the data stored on any mediawiki page if I want to.
The possible workaround here is NOT to store some data in the wikipages and create SpecialPages with strict access control instead. For instance Wikipedia uses AbuseFilter extension where some rules are hidden from the eyes of ordinary people: http://en.wikipedia.org/wiki/Special:AbuseFilter
----- Yury Katkov, WikiVote
On Sun, Aug 11, 2013 at 7:27 AM, Pierre Labrecque pierre.labrecque@live.cawrote:
It seems like a well balanced response :-) So if we compare ACL extensions to Windows, we will say that it' stable, but may crash sometimes. I would like to thank you all again for all these varied comments. It really help !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto: mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Saturday, August 10, 2013 10:24 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
In fact there are some ACL extensions that are used by consultancies, see [1], [2]. Bluespice is probably one of the coolest MediaWiki-based enterprise system which can be used entirely or as part of your enterprise wiki. What you should always have in mind is that you don't have a guarantee that the information you've hidden is unaccessible. In other words you can use ACL extensions so that different groups of your users can see different sets of pages, but you certainly don't want to store the people credit cards numbers in a hidden pages.
[1] http://diqa-pm.com/de/Main_Page [2] https://gesinn.it/de/semantic-apps
Yury Katkov, WikiVote
On Sun, Aug 11, 2013 at 5:04 AM, Pierre Labrecque pierre.labrecque@live.cawrote:
Yes, I understand... unfortunately, I understand :-) Last question: if all this is true (ACL side), what do you think of: http://www.blue-spice.org/ It seems they use an ACL extension as a workaround of the MW limitations, no ? Thanks again for all your comments !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto: mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tom Sent: Saturday, August 10, 2013 6:48 PM To: MediaWiki announcements and site admin list Cc: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
http://en.wikipedia.org/wiki/Access_control_list
http://www.mediawiki.org/wiki/Security_issues_with_authorization_exten sions
By design MW is not a CMS. You need a content management system with a good ACL built in.
You are asking for too much with your example but a CMS could handle it just fine. e.g. Type 'Secret Docs' - Tech 1 could be a Company A, B, C maintainer. Tech 2 could be a Company C, D, E, F maintainer. Tech 3 could be a Company A and E maintainer. All 3 techs could also be in a Type 'Public Docs' group.
You can take it even further with Tech 3 being a read only user. So the tech could read Company A and E docs on Tech 1 can edit A and Tech 2 can edit E.
MW does have permissions but they are group based. ACL in a CMS can compare group, user, content(page), category, state(read, edit, etc.) then make sure a user has met every Access Control before proceeding.
Tom
On Aug 10, 2013, at 3:21 PM, Pierre Labrecque pierre.labrecque@live.ca wrote:
E
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Saturday, August 10, 2013 11:43 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
sorry: I can retrieve the data stored on any mediawiki page if I want to.
Yury Katkov, WikiVote
Hello again,
I know that the mailing list is probably not the good place for this question, but I would like to know how you can do that (bypass Lockdown and access data stored in a mediawiki page)? I tried to do some search on Google on this, but didn't find something... OK, I'm a new with Mediawiki, but didn't find something... If you can give me a link which explain...
Thanks !
Pierre
Ok, maybe that sounded too arrogant :-), but look, there are several dozens of ways to read information stored on a wikipage, I perfectly understand that there is a lot of work needed to close the access through all these channels. For some channels, experience shows, it's impossible to close access without patching the core:
1) go directly to the page 2) transclude the page into another page 3) use MediaWiki API 4) if you use extensions, for example DPL or Semantic MediaWiki, retrieve the data with their queries 5) use Special:Export 6) use RSS
Oh, I've found a list here: http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
----- Yury Katkov, WikiVote
On Sun, Aug 18, 2013 at 3:33 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Saturday, August 10, 2013 11:43 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
sorry: I can retrieve the data stored on any mediawiki page if I want to.
Yury Katkov, WikiVote
Hello again,
I know that the mailing list is probably not the good place for this question, but I would like to know how you can do that (bypass Lockdown and access data stored in a mediawiki page)? I tried to do some search on Google on this, but didn't find something... OK, I'm a new with Mediawiki, but didn't find something... If you can give me a link which explain...
Thanks !
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
" Ok, maybe that sounded too arrogant :-),"... LOL
I've found the same page, and also this one: http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions where we can see that Lockdown seems green, except in some cases: 1- no page-based access control: in our case, we don't care as we want to lock at a namespace level 2- Add ACL by editing page: same answer 3- Add ACL via Special pages: who care... we do it in LocalSettings.php 4- other points are in gray: title listed, but not content. So if we don't write something "confidential" in the title, where is the problem ? I don't know if these info are accurate...
Now: 1- I'm not a perfect newbie, but absolutely not an expert too... 2- I just want to see what is the real risk in a corporate environnement (not an Internet site... on an intranet only)
Thanks for your answer !
Pierre
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Sunday, August 18, 2013 2:50 AM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
Ok, maybe that sounded too arrogant :-), but look, there are several dozens of ways to read information stored on a wikipage, I perfectly understand that there is a lot of work needed to close the access through all these channels. For some channels, experience shows, it's impossible to close access without patching the core:
1) go directly to the page 2) transclude the page into another page 3) use MediaWiki API 4) if you use extensions, for example DPL or Semantic MediaWiki, retrieve the data with their queries 5) use Special:Export 6) use RSS
Oh, I've found a list here: http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
----- Yury Katkov, WikiVote
On Sun, Aug 18, 2013 at 3:33 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Saturday, August 10, 2013 11:43 PM To: MediaWiki announcements and site admin list Subject: Re: [MediaWiki-l] Mediawiki as an Enterprise wiki
sorry: I can retrieve the data stored on any mediawiki page if I want to.
Yury Katkov, WikiVote
Hello again,
I know that the mailing list is probably not the good place for this question, but I would like to know how you can do that (bypass Lockdown and access data stored in a mediawiki page)? I tried to do some search on Google on this, but didn't find something... OK, I'm a new with Mediawiki, but didn't find something... If you can give me a link which explain...
Thanks !
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
One cheap and simple access control to confidential information would be for external links to be used. External to the wiki, but not to your network. Such as a file share where the client specific documentation exists and access controls, such as the usual filesystem/group/user level access controls exist. That way, if someone in the accounting group is reading the wiki, they cannot access Operations/ClientX files, as only the ClientX group can access that information. You could even do what we did at one enterprise I was at, vlan restrict certain larger groups for courser level access control. We had administrators on one vlan, equipment on another, power users on yet another and general users on yet another (with some highly specialized groups also vlan restricted for legal/financial reasons).
The path of least resistance on a labor factor is group share access, with wiki external links to the shared file(s). It would work, it's simple, it's not labor intensive and can quite probably capitalize upon existing data structure.
On 8/9/13 11:10 PM, Pierre Labrecque wrote:
Hello,
(sorry for my poor English.)
This is probably a recurring question.
I work for an IT company of around 80 000 employees and we would like to build an enterprise wiki, where we will put all our technical documentation (how to, troubleshooting, scripting, etc.).
80 000 employees, but this wiki will be for 1000 of them. It may generate a minimum of 200 000/300 000 pages + images + etc.
You have to know that in some of our documentation, we have usernames and passwords, or maybe firewall configuration, etc. for different customers.
Of course, I know that Mediawiki cannot provide a per page/category security (at a read level): my understanding is that Mediawiki is "Read all pages" or "Access denied to all pages". nothing in between. So we cannot restrict view of some documents to a specific group.
Fine.
So let's say that it's not a problem and that all our technicians will be able to read all the technical documents, of all our customers.
Someone told me that we just don't have to put some confidential informations in our wiki documents (no user/password/confidential config/etc.).
Fine. But where ? If we don't put them in the wiki pages, it means that the users will have to go in the wiki for the basic informations, then go on another tool to have the confidential info.
Now, my question: how do you manage this ?
I really love Mediawiki and would like to implement it in our business, but I haven't enough information on how this can be implemented in the reality of a business.
And no: no budget to buy something like Confluence.
I have try Dokuwiki, XWiki, Tiki, MoinMoin, many others. I love Dokuwiki too, but wasn't sure enough it was a strong tool to be able to manage that amount of pages/images/. Anyway, I always come back to MediaWiki. I don't know why.
Best regards,
Pierre
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org