Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "SensiNact/Gateway Security"

(Add your bundle to sensiNact)
(Add an user)
Line 65: Line 65:
  
 
To add a user, you need to send the following information:
 
To add a user, you need to send the following information:
 +
* '''SUID''': a unique identifier (usually the higher number in the column increased by 1). This value is set automatically by the database when it creates the entry;
 
* '''SULOGIN''': the username of the user;
 
* '''SULOGIN''': the username of the user;
 
* '''SUPASSWORD''': the MD5 encoded password (sensiNact does not encode the password);
 
* '''SUPASSWORD''': the MD5 encoded password (sensiNact does not encode the password);

Revision as of 09:24, 13 December 2017

User access level

A first level of security is reached by the way of some of available security "tools" in the OSGi environment: ServicePermission and ConditionalPermissionAdmin. The ServicePermission is a module's authority to register or use a service:

  • The register action allows a module to register a service on the specified names.
  • The get action allows a module to detect a service and use it.

Permission to use a service is required in order to detect events regarding the service. Untrusted modules should not be able to detect the presence of certain services unless they have the appropriate ServicePermission to use the specific one. The ConditionalPermissionAdmin is framework service to administer conditional permissions that can be added to, retrieved from, and removed from the framework.

The sensiNact gateway defines service permissions in such a way that access to the ones it provides is forbidden excepted if a specific condition is met (a sensiNact specific conditional permission). This condition being that the client is the sensiNact SecuredAccess service. sensiNact services also have to use the SecuredAccess to be able to “talk” to each other’s; Modalities of such exchanges depend on the UserProfile of the user of these services (the user can be the system itself). A UserProfile can be defined at each level of the hierarchical sensiNact resource model: ServiceProvider, Service, and Resource. Five UserProfiles exist for which predefined access rights are defined:

  • Owner,
  • Administrator,
  • Authenticated,
  • Anonymous,
  • Unauthorized.

When asking for a data structure of the sensiNact resource model, the access rights of the user are retrieved; the set of this user's accessible AccessMethods for the specific data structure is built and returned as part of the description object. Each future potential interaction of the user on the data structure will be made by the way of this description object. For a remote access a security token is also generated and transmitted to the user, to avoid repeating the security policy processing. A token is defined for a user and a data structure (and so it previously created description object).

The Security & Dependability functional block is used for authentication and to retrieve identity material from which it will be possible to associate a user and a sensiNact resource model data structure to a UserProfile.

In addition to the database managed by the Security & Dependability functional block, used to authenticate a user and to retrieve its identity in the system, the sensiNact platform manages an internal database allowing to link this identity to a UserProfile for a specific data structure. For all data structures for which the user has not been registered the Anonymous user profile is used by default (except if the owner of a resource has defined this default profile to another one). The internal database also gathers information relative to the minimum required UserProfile to access to data structures. This definition can be made at each level of the resource model, knowing that if no UserProfile is defined for a data structure, the one specified for its parent is used.

For example, according to the figure below, a user trying to access to the ServiceProviderX for which its UserProfile is Anonymous will receive a description object in which only one Service will be referenced (ServiceX1), containing a single Resource (ResourceX1S2) providing two AccessMethods: GET and SUBSCRIBE.

sensiNact security

Certificate

(This section need to be consolidated)

sensiNact also allows only the certified bundle to be able to provide data to the user. The bundles have to be signed using a certificate and the generated SHA has to be added into the database in order to sensiNact to validate a bundle. If the bundle is not valid, it will run but it will not have enough rights to access to the core.

Generate your own keystore

To generate a new keystore.jks, you can use the following command (more information at the following address [1]):

keytool -keystore keystore.jks -genKey -alias <alias>

Add your bundle to sensiNact

In the file sensinact.sqlite, in the datastore folder of your distribution, locates the BUNDLE table. In this table, create a new entry with the following values:

  • BID: a unique identifier (usually the higher number in the column increased by 1). This value is set automatically by the database when it creates the entry;
  • SAUTH: ;
  • OPID: ;
  • BNAME: the name of the bundle as it appears in the Manifest;
  • BSHA: the value of the SHA-256 as it appears in the SELFSIGN.SF file under the key SHA-256-Digest-Manifest.

Provision the database

The default database available in sensiNact is a SQLite database. To interact with the database, you can use the command line tool SQLite3.

The database is composed of 11 tables:

  • AGENT: this table is used to declare a trusted agent;
  • APPLICATION: this table is used to declare the applications allowed to run on the AppManager;
  • AUTHENTICATED: this table links the users from the SNAUSER table to the objects from the OBJECT table. It allows to fine tune the access right of the users on the sensiNact data model;
  • BUNDLE: this table is used to declare the trusted bundle allowed to register providers in sensiNact;
  • METHOD: this table describes the available methods in sensiNact. This table shouldn't be changed;
  • OBJECT: this table is used to declare the objects, i.e., providers, services and resources, and the bundle were they belong;
  • OBJECT_ACCESS: this table defines the groups of objects. This table shouldn't be changed;
  • OBJECT_PROFILE: this table describes level of access that can be associated to an object in the table OBJECT. This table shouldn't be changed;
  • OBJECT_PROFILE_ACCESS: this table defines relation between the table OBJECT_ACCESS and OBJECT_PROFILE. This table shouldn't be changed;
  • SNAUSER: this table is used to declare the users of the sensiNact gateway;
  • USER_ACCESS: this table defines the group of users. This table shouldn't be changed.

Add an user

To add a user, you need to send the following information:

  • SUID: a unique identifier (usually the higher number in the column increased by 1). This value is set automatically by the database when it creates the entry;
  • SULOGIN: the username of the user;
  • SUPASSWORD: the MD5 encoded password (sensiNact does not encode the password);
  • SUMAIL: the e-mail of the user;
  • SUPUBLIC_KEY: the unique public key of the user. sensiNact does not generate this key. This key is meant to be shared with the owner of the devices in order for them to grant or deny access to an object to this user.

To add an user to the database, here is an example of the SQL command:

INSERT INTO SNAUSER(SULOGIN, SUPASSWORD, SUMAIL, SUPUBLIC_KEY) VALUES ('username', 'md5password', 'e@ma.il', 'public_key');

Back to the top