External services security
Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies.
- 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
The external API may be used from different places:
- directly from PHP - no authentication, current user session is used ($USER, $SESSION)
- from full 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
- 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
- RSS feeds, iCals, etc. - token login, no permanent session
- external server interface (SOAP, REST, RSS, etc.) - deals with tokens, emulates user session, parameter processing
- 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
- 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 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..
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.
Full web services
New webservice 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.
User preferences may be later used for storage of extra data such as public certificates.
Specifies which user may use each web service. All web service available through full WS layer should have restrictedusers flag enabled in the service definition.
|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|
|timecreated||int(10)||time when this record added|
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
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.
|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