External services security: Difference between revisions
Line 9: | Line 9: | ||
* open RSS feeds - no security at all | * open RSS feeds - no security at all | ||
* chat_sid tokens - generated separately for each user in each chat | * chat_sid tokens - generated separately for each user in each chat | ||
* calendar hash from user name, password and salt | * calendar export - hash from user name, password and salt | ||
* hacky cookie emulation in visual gradebook plugin | * hacky cookie emulation in visual gradebook plugin | ||
Revision as of 18:59, 21 May 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
Types of token
We need several types of tokens
- token sharing/linked to active session, should time out or be destroyed at the same time as session (ex.: chat) - shared $SESSION and $USER
- permanent token, revokeable by user (ex.: RSS feeds, web services) - emulated $SESSION and $USER
In the second case we need to deal with performance problems if many repeated request expected. This can be dealt with later.
API layers
Three layers:
- 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()!
Implementation
New external_functions table
List of external functions. Created automatically by parsing of external files.
Field | Type | Default | Description |
---|---|---|---|
id | int(10) | auto-incrementing | |
component | varchar(100) | Component where function defined. | |
name | varchar(150) | Name of function | |
enabled | int(4) | function enabled, functiosn might be disabled for security reasons | |
phpfile | varchar(255) | location where function defined | |
functionparams? | text | null | ?some form of param description? |
requireslogin | int(1) | extra information - some external functions may not require $USER |
New external_services table
Service is defined as a group of functions.
Field | Type | Default | Description |
---|---|---|---|
id | int(10) | auto-incrementing | |
component | varchar(100) | Component where service defined. | |
name | varchar(150) | Name of service (gradeexport/xml, mod/chat/export) | |
enabled | int(4) | service enabled, for security reasons some services may be disabled | |
version | varchar(10) | version string | |
requiredcapability | varchar(150) | null | Required capability (tested in security context or system context if no security context specified) |
New external_services_functions table
Specifies functions used by services.
Field | Type | Default | Description |
---|---|---|---|
id | int(10) | auto-incrementing | |
externalserviceid | int(10) | foreign key, reference external_services.id | |
externalfunctionid | int(10) | foreign key, reference external_functions.id |
New external_tokens table
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 | |
contextid | 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 |
New external_sessions table
Alternative session handling for scripts that are not allowed to access http cookies such as flex apps or external applications. The $SESSION is a true session which shares locking with the real http session. The token is automatically destroyed when http session ends (timeout, logout, login, etc.)
Field | Type | Default | Description |
---|---|---|---|
id | int(10) | auto-incrementing | |
userid | int(10) | foreign key, references user.id | |
token | varchar(128) | private access key value | |
contextid | 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 | |
sid | varchar(128) | PHP session id - links sessions table or files directly for legacy session types |
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.