Difference between revisions of "External services security"

Jump to: navigation, search
(See also)
(Simplified web services)
Line 38: Line 38:
  
 
==Simplified web services==
 
==Simplified web services==
This type of web service is using simple username+password authentication (in future could be username+certificate). The communication integrity/privacy can be protected by https.  
+
This type of web service is using simple username+password authentication (in future could be username+certificate). The communication integrity/privacy can be protected using https. Each external application is using own user account. These user accounts can not be used for normal login into moodle vie web interface.
 +
 
 +
This type of WS is intended primarily for integration with student information systems or other enterprise software.
  
 
===webservice auth plugin===
 
===webservice auth plugin===
Line 85: Line 87:
 
| time when this record added
 
| time when this record added
 
|}
 
|}
 +
 +
===Steps needed to configure simple web services access===
 +
 +
# enable simple web services - global switch affecting all simple web services (admin UI)
 +
# create new service in some local plug-ip (add code into /local/yourplugin/db/services.php)
 +
# add new user, set auth plugin to '''webservice''' (normal add user UI)
 +
# enable web service layer plugin (admin UI)
 +
# add user into list of users that are allowed to use specific external services (admin UI)
 +
# set up user permissions needed in function implementations
 +
# set up permission to use specific web services (optional, services do not need to specify required capability)
  
 
==Application embedding==
 
==Application embedding==

Revision as of 22:12, 7 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.

Overview

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

Design

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. simple 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
  5. full WS layer with emulated session - performance is the main issue here, the faking of $USER and $SESSION is very expensive, we will have to use some token which mimics the browser cookies.

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

Implementation

PHP API

This simplest case of using the external API. The calling call has to make sure the current $USER and $SESSION is valid. Optionally the caller may set up the context restriction manually. This should be the easiest way to start with Moodle modifications.

Simplified web services

This type of web service is using simple username+password authentication (in future could be username+certificate). The communication integrity/privacy can be protected using https. Each external application is using own user account. These user accounts can not be used for normal login into moodle vie web interface.

This type of WS is intended primarily for integration with student information systems or other enterprise software.

webservice auth plugin

It is recommended to create separate user for each external application. The benefit of this auth type is that it can not be used for normal log-in from the web interface. User preferences may be later used for storage of extra data such as public certificates.

WS entry point

Separate php file /webservice/xxx/simpleserver.php

external_services_users table

Specifies which user may use each simplified web service. All services available through this interface should have the restrictedusers flag enabled.

Field Type Default Description
id int(10) auto-incrementing
externalserviceid int(10) foreign key, reference external_services.id
userid int(10) foreign key, reference user.id
iprestriction char(255) restrict access to some ips or subnets only
validuntil int(10) invalidate after
timecreated int(10) time when this record added

Steps needed to configure simple web services access

  1. enable simple web services - global switch affecting all simple web services (admin UI)
  2. create new service in some local plug-ip (add code into /local/yourplugin/db/services.php)
  3. add new user, set auth plugin to webservice (normal add user UI)
  4. enable web service layer plugin (admin UI)
  5. add user into list of users that are allowed to use specific external services (admin UI)
  6. set up user permissions needed in function implementations
  7. set up permission to use specific web services (optional, services do not need to specify required capability)

Application embedding

Capabilities

It would not be practical to list all approved users, instead we can use capabilities for access restrictions. The required capability is given in the service definition table.

RSS and other feeds

external_tokens

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

See also