User:Jeblad/Qualified access

Qualified access to another system can be done according to the users credits on 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 enable or disable those left as necessary at the data page in the Mediawiki-space.

Fundamental operation
Fundamental operation is to add a parser function as a link in the running text, to add a link to a toolbox through LocalSettings.php, or to add a link generated by javascript somewhere on a page. All of them creates a link to a special page, which may render itself or redirect to the specific service. This page takes a parameter describing the service which identifies the actual configuration set, or a parameter to identify the protected resource at the service. A call to this special page will be Special:Qualifiedaccess/identificator  to go to a given resource at any service through a intermittent page,  Special:Qualifiedaccess/service  to go to a specific service or  Special:Qualifiedaccess/service,identificator  to go to a specific resource on a specific service. 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) The user clicks on a prepared link, goes to the special page or in some way makes a query for access to the protected resource
 * 2) Access to each service are enabled if credentials are deemed sufficient, that is those described as wanted credentials from the data page and those described as allowed credentials from the configuraton matches the users actual credentials; actual credentials are then collected in a data packet together with a timestamp and service specific data
 * 3) The complete request is then signed with the wikis private key and optionally encrypted with the external service public key
 * 4) 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
 * 5) The external service may decrypt the data packet with its own private key if its encrypted, and then check the signature with the wikis public key, – if success it will proceede
 * 6) The external service checks timestamp of request to see if this is within allowed time window, – if success it will proceede
 * 7) The external service checks its own data in the request, and may or may not do any further qualifications of the transfered credentials, – if success it will proceede
 * 8) The external service allow access to the protected service or specific resource

Note that the user may choose to automatically redirect accesses for the service after the first logon.

Not also that if point number 2 fails, then the user can be redirected directly to the service assuming that the service has some pay for service solution in place.

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 as information leaks already at this point. 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 obfuscated 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 chosen 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.

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 infer 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. To avoid this all logged in users will be routed through the special page when accessing links to the given service. This lessens the correlation between user names at the wiki and external service.

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.

Also make the directory  or whatever directory you configure GnuPG to use. Inside this directory make a empty config file

Use the gpg.conf for any additional configs that should not be overridden by those in.

Build or import a new keypair for the site, and if necessary remove the passphrase. This is not in general advisable as the private key has very little protection without the passphrase. Yet, if we should use this we would have to store the passphrase as clear text somewhere and that will not lead to a better security. We could make a wrapper command that would only allow specific calls and not allow anyone to dump the content of the keyring. We have nonetheless not done this. There are a few options but it is out of scoop for the extension itself.

Public keys for the services should be imported as necessary from key servers, but can also be added through gpg on the command line.

Most people will not want to see the intermediate processing, so to hide the output update  with the following

To make it easier for those who wants to check this it is advisable to add a gadget in User interface gadgets that turns the textarea back on.

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.

The tag is only used on the data page «Mediawiki:qualifiedaccess-definitions» in the Mediawiki namespace.


 * title : 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. The title can have any form, except contain quotes.


 * service : Identifier for the given dataset. This is used for filtering if a service name is explicitly given in the url, or it is implicitly given as an anonymous parameter. If no known service is given all are used. It might also be used as an alias for title. The name should be easily readable in an url.


 * resources : 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. Only alphanumerics and a few other characters are allowed. (There should be implemented a wild card matching method.)


 * action : The actual url to use for the lookup of the resource. This is the termination of the request at 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.


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


 * success : Data sent back to the service on a successful check of the credentials. This could be any text string but is typically some kind of token or identifier.


 * failure : Data sent back to the service on an unsuccessful check of the credentials. This could be any text string but is typically some kind of token or identifier.


 * rights : 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 to determine if the preparation of a request is successful. (Use of exclamation marks are not implemented and all listed rights are reported)


 * groups : 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 as unsuccessful. Groups marked with a exclamation mark are hidden from the external service, yet they are used to determine if the preparation of a request is successful. (Use of exclamation marks are not implemented and all listed groups are reported)


 * features : A comma-separated list of features to add to the request. If given, and without any features to report, the request will be marked as unsuccessful.
 * id : This is the user id, it will be reported to the external site if given (true in config to turn on reporting)
 * name : This is the user name, it will be reported to the external site if given (true in config to turn on reporting)
 * realname : This is the users real name, it will be reported to the external site if given (true in config to turn on reporting)
 * email
 * authenticated
 * registration : This is the time since the user registered the account, obfuscated as number of weeks or months since registering, it will be reported to the external site if given (true in config to turn on reporting)
 * editcount : This is the users editcount, obfuscated by only keeping one significant digit, it will be reported to the external site if given (true in config to turn on reporting)


 * editlimit : Minimum numer of edits to get a successful request. It is compared to editcount.
 * daylimit : Minimum number of edits during a 24 hour period to get a successful request. This comes from the recent changes table and is a somewhat heavy test.
 * weeklimit : Minimum number of edits during a 7 day period to get a successful request. This comes from the recent changes table and is a somewhat heavy test.
 * agelimit : Minimum time since creation of account. It is compared to registration.
 * key : Identificator for the external websites' public key. If given and not listed at the internal public keyring or at the keyserver the request will terminate as unsuccessful.


 * keyserver : An external keyserver to be used for look up of public keys for the external service. If the given keyserver can't provide the public keys the request will terminate as unsuccessful.


 * mode : How to process the request; to do a encrypt with an implied sign, an armour with an implied sign, or a explicit or implicit clearsign.

The final rendered special page will contain and visualize all parts to be submitted to the external site, and a button to submit the prepared dataset. Requests with failed credentials has a message about this. This should make it completely 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.

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.