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

SensiNact/Gateway Security

< SensiNact
Revision as of 08:20, 12 July 2017 by Remi.druilhe.gmail.com (Talk | contribs) (Added certificate section)

Security mechanism

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.

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>

Back to the top