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
Fundamental operation is to add a parser function as a link in the 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 encryption will be done.

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

Unless otherwise configured the special page will visualize all data to be sent to the external web site, although not necessarily in the same language or format.


 * Steps in the process
 * 1) User clicks on a prepared link
 * 2) The special page gets its describing and protected page from the Mediawiki-room
 * 3) Each service are then described by wanted credentials (features from tag) which is filtered through allowed credentials (features from DefaultSettings/LocalSettings) and successfull credentials are collected in a data packet
 * 4) A timestamp are preprended to the data packet
 * 5) The customer id are prepended to the data packet (Should be deducted from the signants public key)
 * 6) The complete request may be signed with the internal wikis private key and encrypted with the external service public key (encryption is optional, signing is not)
 * 7) The user visually inspects the result and accept its content, and submits the request to the external service by delivering this data packet through his browser as a GET or POST request, – if the user does not continue no information will be submitted
 * 8) The external service may decrypt the data packet with its own private key, and then check the signature with the wikis public key, – if success it will proceede (encryption is optional, signing is not)
 * 9) The external service checks timestamp of request to see if this is within allowed time window, – if success it will proceede
 * 10) The external service checks customer id against its own lookup for such requests to see if this is an allowed request, – if success it will proceede (Should be deducted from the signants public key)
 * 11) The external service may or may not try to do further qualifications of the given credentials, – if success it will proceede
 * 12) The external service allow access to the protected service or specific resource

If allowed access to a protected service, like an news archive, further accesses might be done by following direct links. For this to be successful a cookie should be set in the browser to make the interaction more effective.

''A small Javascript in the browser could change recognized links in certain ways as to redirect the user through the special page once for each session, and then later let the user do direct accesses through links without going through the special page each time. This will although represent an increased leak of data that will make it easier to identify the user.''

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 overall 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 and make it necessary to use more constraints to identify an user.

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 number of weeks, and if sufficient old it is rounded to number of months or even 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 features and groups should be set to «autoconfirmed». This is sufficient to detect wikipedians if there is a minimum limit on edits, and if a blocked state for the user makes the access fail.

Note that due to the field referrer in the head of the http-request, direct linking between articles with on-going editing and external sites will in general lead to a situation where it might be possible to infere which logged in users have which ip-address, and thereby who owns the connection at a given moment and edits under a given user name.

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;