User:Jeblad/Qualified access

Jump to: navigation, search

Qualified access to another system can be done according to the users credentials on the wiki. Such credentials 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 and pass on the user if there are sufficient credentials. Defaults can be explicitly set in LocalSettings.php to enable those credentials allowed to be transfered, and then further allow or deny access given those left as specified at the page used for definitions in the Mediawiki-space.

Given the credentials access can be granted — which means the user will be given access, it can be postponed — which means the user has to pass some check on the site or will have to pay a fee, or it can fail completely. In the last case the service will not appear on the special page.

There are two types of operation; one is to log on to a service and then continue to work on the site, the other is to ask for a specific resource and then be granted a limited access to that. If a resource is queried the user may or may not be logged off from the service as such, depending on the sites internal state engine.

Fundamental operation[edit | edit source]

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/resource]] 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,resource]] 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.

When accessing the special page the available resources are filtered and only those who make the external resource available will be listed. If no such resource is available the special page will prepare an empty request, if no specific service is given then all listed services will be used, which typically is done for log on for those that allow this.

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 and/or resource are granted if credentials are deemed sufficient, that is those described as wanted credentials from the data page and those described as allowed credentials from the configuration matches the users actual credentials; actual credentials are then collected in a data packet together with a time stamp 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 proceed
  6. The external service checks time stamp of request to see if this is within allowed time window, — if success it will proceed
  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 proceed
  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.

Note 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.

Note also that when access is not granted this may not lead to failure to sign in, but may lead to additional steps on the external site. Ie failure=pass ... The external site may also have alternate solutions when signed log in fails completely.

Privacy issues[edit | edit source]

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, although it will not remove the correlation it will merely remove the page name from the referrer field.

States on the external site[edit | edit source]

State transfers on the external site should approximate the following.

  • If a user request a service or resource and has an other affiliation to the external site, it may or may not use the credentials as given or the credentials from the alternate affiliation
  • When a user is not logged in, and is granted access to a service, and no resource is given, the user should be logged in
  • When a user is not logged in, and is granted access to a service, and a resource is specified, the user should be given access to the resource but should not be logged in
  • When a user is logged in, and is granted access once more to a service, and no resource is given, the user should keep the logged in status
  • When a user is logged in, and is granted access once more to a service, and a resource is specified, the user should be given access to the resource and the user should keep the logged in status

Methods for logging off external sites are left unspecified.

Installation[edit | edit source]

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

Note that installation of gpg is a prerequisite for the extension.

  1. Create a new folder (directory) in the following location:
  2. Download the following files:
  3. Copy the files to the new QualifiedAccess folder
  4. Add the following code to your LocalSettings.php (at the bottom)
require_once( "{$IP}/extensions/QualifiedAccess/QualifiedAccess.php" );
  1. Adjust the following code to your needs (not up to date!!)
If rights, groups or features are unset they can only be used for internal tests, if set to true they can also be transferd to the external site, and if set to false they can not be used for any testing at all. A few rights, most groups and some features should be blocked against all use.
$wgQualifiedAccessRights = null;                  // this should not be used
$wgQualifiedAccessGroups['patroller'] = false;    // to specific
$wgQualifiedAccessGroups['sysop'] = false;        // to specific
$wgQualifiedAccessGroups['buraucrat'] = false;    // strictly internal
$wgQualifiedAccessGroups['oversight'] = false;    // strictly internal
$wgQualifiedAccessGroups['steward'] = false;      // strictly internal
$wgQualifiedAccessFeature['username'] = false;    // private information
$wgQualifiedAccessFeature['realname'] = false;    // private information
//$wgQualifiedAccessFeature['blocked'] = false;     // private information

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 /var/gnupg or whatever directory you configure GnuPG to use. Inside this directory make a empty config file gpg,conf

# mkdir /var/gnupg
# touch /var/gnupg/gpg.conf
# chown -R www-data /var/gnupg
# chgrp -R www-data /var/gnupg
# chmod 600 /var/gnupg/*
# chmod 700 /var/gnupg

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

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. [1]

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 Mediawiki:Common.css with the following

.qa-form textarea {
  display: none;

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[edit | edit source]

The extension will enable a parser function which will prepare links to the special page. This will only be used to identify a resource by its name, and should have no security implications. The parser function itself will not do any testing of the validity of the request, it is only a simple accessor. This is primarily used to access a service or a resource on a specific service.

first parameter 
Name for the service to be accessed. Should conform to a specified service given on the definitions page.
second parameter 
Identifier for the resource to be accessed. Should conform to the form used for this type of identifier.

The extension will also enable magic words to prepare links to resources through the special page. This is the most common use of the extension. Typically it will be used for linking the ISSN-number for a serial paper to the special page, or a DOI-number or similar, leaving the parsing of the number to the extension itself.

magic words 
This is a list of regular expressions, and when hits are found in the text the matched strings are delivered as is but url escaped to the extension.

Lastly the extension will enable a tag function for use on the definitions page, containing specifications for the request, for a resource or service at the external web site. All features to be used must be enabled in LocalSettings.php and must also be identified by the tags on the definitions page. If items in rights, groups or features are given with an exclamation mark they are transfered to the external site, without that exclamation mark they are only used locally. 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.

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.
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.
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.)
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.
How to access the external resource, typically one of get or post. Configuration might restrict or allow specific request methods.
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.
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.
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.
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.
A comma-separated list of features to add to the request. If given, the actual values will be used possibly in combination with given limits.
This is the user id.
This is the user name.
This is the users real name.
This is the users email address.
wetter the user is authenticated.
This is the time since the user registered the account, obfuscated as number of weeks or months since registering.
This is the users editcount, obfuscated by only keeping one significant digit.
Minimum numer of edits to get a successful request. It is compared to editcount.
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.
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.
Minimum time since creation of account. It is compared to registration.
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.
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.
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.
When to include the service. On "grant" all tests must evaluate to true. On "fail" at least one tests must evaluate to false. On "all" it will always be included. If not defined then the settings from LocalSettings.php defines the a action.

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 time stamp, site name and the users ip-address will always be embedded in the packet.

Signing[edit | edit source]

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 recipient that is self contained, and without any need for the recipient to do further communication with the wiki-based service or the user to establish the users credentials.

Any setup of the subsystem are done through LocalSettings.php, and additionally through mode. This string is parsed and keywords are passed through a lookup table and added to the subsystems parameters. If the string says «encrypt» the public key of the external site will be used for encryption of the packet. If it says «clearsign» the private key of the local site will be used for making a cleartext signature of the packet. If it says «armor» the resulting text will be armored. The internal service keypair is associated with $wgPasswordSender, and a private key for this user should be available on the secret keyring.

Example[edit | edit source]

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.

   keyserver="" >
 Here goes the description

See also[edit | edit source]

References[edit | edit source]

  1. Russell Coker: Is a GPG pass-phrase Useful?