Meego Wiki
Views

Architecture/Documentation/Security/SSO

From MeeGo wiki
< Architecture | Documentation
Revision as of 10:49, 21 January 2011 by Miikadeluxe (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


SingleSignOn Architecture
Subsystem Architecture Specification

Contents

Document control

References

Tag Document name Repository (with hyperlinks)
[ArchGoals] Architecture Goals [xxx]
[SystemModel] Maemo System Model [xxx]
[PDBv2] Package database [xxx]

Glossary

Acronym or term Description
API Application Programming Interface
SASL Simple Authentication and Security Layer

Summary of changes in current version

Update of changed figures and descriptions.

Architecture

Licensing and IPR view

signond component is licensed as GPLv2 due to dependencies. SSO client library is licensed as LGPLv2.1.

Authentication plugins are proprietary, except the built-in plaintext and SASL plugins. SASL plugin is based on open source component.

There are no suitable available open source solutions, which would match the requirements even closely.

Configurability

Locations for database and plugins can be configured during compilation time.

Packages

Package ver doc dev dbg
libsignon-qt 0 doc dev dbg
libsignon-glib 1 doc dev dbg
signond 0 doc dev dbg
signon-plugins dev
signon-passwordplugin
signon-saslplugin dev
signon-doc
signonui-informer-extension
libsignon-ui 0 doc dev dbg
signon-ui dbg
keychain-ui dbg

Table 3: Packages provided

Performance

General Performance Considerations

  • Plugin system provides flexibility to add features
  • Data set is limited by user credentials
  • Typically users have less than 100 accounts with credentials
  • Some operations require remote server responses and time performance is not critical issue
  • Long operations are asynchronous by default

Memory

  Explanation Size [kB]
Flash/OneNAND Program & library files 2048
Flash/eMMC Credential database 4096
RAM/Idle Signond daemon 850
RAM/Peak Signon-ui 3048

Runtime

  • One daemon running
  • In typical use case 2-6 DBUS messages are sent
  • Token renewal is periodic, depending on service
  • Started on demand
  • Application start time not affected

Power Consumption

Daemon is in sleep when applications do not need authentication. Power consumption is minimal.

Security

SignOn is huge security risk. It is storing user credentials which should be kept safe. This could also include credit card numbers etc.

- Features that require high (admin / root) permissions or are a part of trusted computing base (kernel, etc.)

- User data or personally identifiable information (PII) is handled

- Network connections are used or relied on

- Externally supplied data is being processed

- Financial transactions are processed or billable events are created

- Cryptographic functionality (algorithms, random number generators, protocols) are used or a 'security feature' is being implemented

  • Operational environment of a component or expectations of its operation change

A table below is depicting executables and their credentials.

Credentials required by Single Sign-On subsystem executables
Executable Credential
signond UID::root
signond GID::root
signond CAP::setuid
signond CAP::dac_override
signond CAP::sys_module
signond CAP::sys_admin
signond CAP::mknod
signond CAP::ipc_lock
signond *::sso-encryption-token
signonpluginprocess UID::signon
signonpluginprocess GID::signon

Open items

# Item Status Description
1 Locked device closed Should encrypted filesystem be closed when device is locked?
2 DBUS id closed How to obtain unique identifier of D-BUS peer. Officially not yet supported by Security Framework.
3 Lock code closed Device lock code setting/getting is not defined.
4
5
Personal tools