User:Jeblad/Qualified access

A qualified access to another system is done according to the usercredits inside the wiki. Such credits can be several features such as user rights, number of contributions, time since registering, time since last block or even user name. The extension identifies some such features. Defaults can be changed in  to enable configuration of each value, and then further enabled or disabled as necessary.

Fundamental operation is to add a parser function in running text, or to add link to a toolbox through LocalSettings.php, or to add a javascript link somewhere on a referencing page, which creates a backlink to a special page. This takes one parameter describing the resource which identifies the actual configuration set. A call to this special page will be Special:Qualifiedaccess/resource. During processing of this special page the necessary signing and/or encrytion will happend.

If the special page is accessed with an identificator an access for a specific external resource is prepared, and if necessary the available resources are filtered, and only those who make this external resource available will be listed. If no identificator is available the special page will prepare an empty request, which typically is used for an automatic log on to the external resource.

Unless otherwise configured the special page will display all data to be sent to the external web site.

Privacy issues
Credentials can be selectively enabled or disabled. To remove reporting of a credential to the external entity does not in general makes the privacy issue less important. The success of a request in itself represents a privacy issue. If sufficient features are enabled, sufficient groups or similar, then the existence of those constraints will establish sufficient constraints to positively identify the user. Wetter reporting the actual features or not does not change the possibility of identifying the person, although it can shift it somehow.

Some of the credentials are obfusicated to make positive identification less likely. Edit counts are rounded to one significant digit. Age of the account are rounded to numer of weeks, and if sufficient old it is rounded to year of creation.

Features and groups should be choosen so they are barely enough to distinguish between successful and failed access. In most situations that will be no use of features and groups should be set to «autoconfirmed». This is sufficient to detect wikipedians if to few edits and blocked state makes the access fail.

Installation

 * Note that this is in an early alpa state and is not production quality!

Note that installation of  is a prerequisite for the extension. wiki-install-folder/extensions/QualifiedAccess
 * 1) Create a new folder (directory) in the following location:
 * 1) Download the following files:
 * 2) * /QualifiedAccess.php
 * 3) * /QualifiedAccess.i18n.php
 * 4) * /QualifiedAccess_body.php
 * 5) Copy the files to the new QualifiedAccess folder
 * 6) Add the following code to your LocalSettings.php (at the bottom)
 * 1) Adjust the following code to your needs (not up to date!!)

You should not enable reporting of username or realname unless necessary, and if so you should inform your users of the consequences. Note also that using sufficient many attibutes in parallell can compromise the users anonymity.

Usage
The extension will enable a parser function which will prepare a redirect to a special page. This will only identify a resource by its name, and should have no security implications.


 * Mediawiki:qualifiedaccess-definitions navngir resurser brukt av spesialsiden, gitt den eksterne identifikatoren som er angitt. Kodifisering av forespørselen til den eksterne siden utsettes inntil det er klart at den kan leveres. Dette vil redusere den nokså tunge operasjonen, og hindre at denne utføres for unødvendige instanser.

The extension will also enable a tag function and according to the definitions it will prepare a POST request, using customised values, for a request towards the given external web site. Any feature not disabled in LocalSettings.php and identified in the local tag function wil be added to the request. If a public key is specified it will be used to sign the request, and it will be downloaded from either of the specified key servers.

Tags are used on special pages from the Mediawiki namespace.

Title for the given dataset. This is used for various messages and should therefore be included. If not given the service is used as an alias.
 * title

Identifier for the given dataset. This is used for filtering if a service name is explicitly given in the url, or is implicitly given as an anonymous parameter. If no known service is given all are used. Might also be used as an alias for title.
 * service

Patterns for matching a specific protected resource at the given service. The matching rules are very simplistic, and only the leading part of the resource name are used for the match process. (This is a security risk(?), and the patterns should be cleaned up properly. There should be implemented a wild card matching method.)
 * resources

The actual url to use for the lookup of the resource. This is the termination of the request inside the external service, and may do some redirecting for the final destination. That is there might be a url for handling the log on phase, and then a redirect to the actual resource.
 * action

How to access the external resource, typically one of get or 'post''. Configuration might restrict or allow specific request methods.
 * method

A comma-separated list of rights to add to the request. If given and there are parameters on the call to the special page, and without any result, the preparation of a request will terminate as unsuccessful. Rights marked with a exclamation mark are hidden from the external service, yet they are used in determine if the preparation of a request is successful. (Use of wxclamation marks are not implemented)
 * rights

A comma-separated list of groups to add to the request (if given, with parameters to the special page and and without any result, the request will terminate)
 * groups

A comma-separated list of features to add to the request (if given, and without any features to report, the request will terminate)
 * features

Identificator for the external websites' public key (email adresses will be autowrapped in angle brackets)
 * key

An external keyserver to be used for look up of public keys (only used for keys for the external service, not for the internal service nor the users keys)
 * keyserver

The algorithm to use for the signing
 * hash

How to process, only to do a clearsign or a encrypt operation
 * mode

The final rendered special page will contain and visualize all parts to be submitted to the external site, and a button to submitt the prepared dataset. This should make it completly visible and transparent to the user what he/she are about to do.

Note that the identificator for the external digital object is delivered directly to the special page in the call to this...

A timestamp will always be embedded in the packet.

It might be necessary to add a value lastedit.

The editcount feature is obfusicated if it is non-zeero. It is then adjusted with a scaling random number and the final number is rounded.

Signing
Signing is done through one of several subsystems, gpg is used as default. Other subsystems may or may not be used as a drop in replacement. It is a primary goal for the signing process to be able to deliver a packet to the recipent that is self contained, and without any need for the recipent to do further communication with the wiki-based service or the user to establish the users credentials.

Usually mode will describe the use of the external service public key. If it says «encrypt» the public key will be used for encryption of the packet. If it says «clearsign» the public key will be used for making a cleartext signature of the packet.

If a scond word is added this will refer to a second pass with the internal service private key. This can also be done by adding the special word double to make two similar passes. By doing a second pass with the internal service private key it is possible to completely verify the origin and content of the packet without making separate callbacks from the external service to the internal one. The internal service keypair is associated with, and a private key for this user should be available on the secret keyring.

If a third word is added, or the special word triple is used, this will refer to a third pass with a private key for the actual user, but as this is under the control of the user he or she has to use additional software to rewrite the request. Normally this will be done by adding a java applet that will intercept the submit process, do local signing in the browser and change the request accordingly. The wiki will use the users public key, the user has to verify the signature and make a new signature with the private key, then the external service can verify the signature with the users public key. This process can be extended to several layers and form a onion-like solution.

Example
Requests to a resource are in general Special:Qualifiedaccess/megarchive. If a specific object are requested the shortform is Special:Qualifiedaccess/megarchive,1234567890. The form without a resource isn't generally supported Special:Qualifiedaccess/,1234567890, but the special page will use a fallback and allow use of all resources to locate the object. Some special forms of identificators is identified as such and cant be used as resource names.

The datasets for the resources resides at pages in the Mediawiki-space. This makes them implicit protected from anyone other than sysops, unless other users are given edit-access to this namespace.

&lt;qaccess feature="rights" action="http://somewhere.on.net" key="webmaster@somewhere.on.net" keyserver="" /&gt;