Difference between revisions of "External services security"

Jump to: navigation, search
Line 1: Line 1:
'''NOTE: this page is obsolete and does not reflect latest development'''
Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies.
Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies.

Revision as of 21:06, 6 October 2009

Moodle 2.0

Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies.


Current solutions:

  • user keys for gradebook import and export - see require_user_key_login() and db table user_private_key
  • open RSS feeds - no security at all
  • chat_sid tokens - generated separately for each user in each chat
  • calendar export - hash from user name, password and salt
  • hacky cookie emulation in visual gradebook plugin


Different uses

The external API may be used from different places:

  1. directly from PHP - no authentication, current user session is used ($USER, $SESSION)
  2. from web service layer - ws is responsible for faking of $USER and $SESSION object, no persistent session is maintained, webservice auth plugin is used for login/password authentication
  3. when embedding external applications - external application receives unique token which is used instead of normal browser session cookie, the session is linked to the current user session in browser, the token is automatically invalidated after logout
  4. RSS feeds, iCals, etc. - token login, no permanent session

API layers

Three layers:

  1. external server interface (SOAP, REST, RSS, etc.) - deals with tokens, emulates user session, parameter processing
  2. public PHP API - functions usable directly from PHP, list generated from inline PHP docs, need to verify all parameters and access control, may access $USER, should not manipulate $SESSION directly, must not read $_POST or $_GET
  3. low level internal API - as fast as possible, basic param validation, no access control, must not touch $USER, $SESSION, $_GET or $_POST, must not use has_capability() or require_login()!

Context restrictions

Context restriction of token validity should be effective against security problems in external applications interacting with Moodle. Some external applications do not have any access to http cookies, solution is to create temporary tokens. Context restrictions would allow us to grant external access to individual activities, courses ,etc..


New database tables


Stores tokens for cookieless access, script runs without real session, $USER and $SESSION is emulated. Use is relatively expensive because each scripts has to initialize accessdata in acceslib.php again. Existing data from user_private_key table are migrated here.

Field Type Default Description
id int(10) auto-incrementing
userid int(10) foreign key, references user.id
token varchar(128) private access key value
restrictioncontextid int(10) security restriction, key usable only in this context, references context.id
externalserviceid int(10) foreign key, references external_services.id
itemid int(10) Service specific item id
iprestriction varchar(255) null IP address restriction, list of allowed addresses
validuntil int(10) null timestampt - valid until date
timecreated int(10) time when key created
lastaccess int(10) time when key last used for access

Examples: gradebook exports, private RSS feeds, web services

New capabilities

New capabilities for external services above. Each function could define capabilities too.

New auth plugin

Some external applications may require creation of new user account types that are not able to login interactively but only using login/pass or certificate. New authentication plugin could solve this problem.

The current design problem that any external actions such as role assign are carried out as nobody or root, it is later not possible to find out who changed what. Another problem is restrictions of external services to some contexts only.

User preferences may be also used for storage of extra data such as public certificates.

New functions

get_external_session_token($restrictioncontext, $service, $itemid, $version)

Returns user token which is used when embedding application or launching external applications. The other application has access to all functions specified in service definition in the restricted context or bellow until the end of current users session.


Each functions that supports restrictions must:

  1.  find out context of request from function parameters - when enrolling user to course it is a course context, when add post to chat it is chat context, etc.
  2. call validate_context_restriction($currentcontext) - Moodle verifies $currentcontext is equal or child of restriction context, if not exception is thrown and script terminates.

The restriction context is stored in some global variable which is initialized in lib/setup.php using data from token tables.

See also