- 1 Introduction
- 2 Installing Onepoint
- 3 Architecture
- 4 Backends
- 4.1 Backends Configuration
- 4.2 Primary Backends
- 4.3 Secondary Backends
- 5 The UI
- 6 Documents
- 7 Videos
- 8 Change History
- 9 Supported Systems
- 10 Auxiliar Manuals
Onepoint enables Systems Integration for the IT environment. Through its disciplines concepts, it allows the integration of IT assets, modules, systems and units into a single and widelly connected among all parts, creating the possibility to creating actions, tasks and flows involving all those parts.
Backends are a Onepoint-specific concept. They are components of the computational environment designed to carry out a task or a group of related tasks for a Discipline. They allow requests and operations on the target systems through Onepoint REST calls. They also allow the integration of asynchronous tasks directly on the target systems, through Onepoint Scripts calls.
For configuration, see Backends Configuration.
Primary Backends are backends that can be instanced, parameterized and extended to integrate environment's own components, such as vaults, user directories, ticketing systems, authentication systems and authorizations systems.
Responsible for user identity authentication. After a positive response from 'login' operation, Onepoint generates a session for operating the system. It's an extensible backend. In other words, it's possible to integrate other authenticators into onepoint, including supporting Multi-Factor Authentication and Single Sign-On tools.
Responsible for managing directory data (user, groups and membership). It's a extensible backend type, allowing integration of external directories.
Responsible for the storage, management and integration of credentials, passwords and secrets. It's an extensible backend, what allows the integration of third-party vault systems.
Access Session Backend
Responsible for the channels and protocols for access establishment, such as RDP and SSH. It's an extensible backend and can support other protocols.
Secondary Backends are internal and/or fixed backends, that can't be instanced, parameterized or extended.
Responsible for the management of access tickets and authorization based on rules for the request. It's not an extensible backend.
Responsible for the records of managed systems. It's not extensible.
Responsible for verification of permissions on the requested resource(s) for the logged in identity. It's not an extensible backend. It works with permissioning based on Access Control Lists, Groups and Inheritance support
Responsible for serving and managing backends. It's not an extensible backend.
Responsible for managing and operating 'workflows'.
Responsible by managing and maintening resources' policies features. They can be:
- Synchronization Policies - Interbackend data synchronization
- Cache Policies - Assigning a backend as cache of another backend
- Expiration Policies - Rules for objects expiration
- Migration Policies - Managing Migration Status
- Access Policies - Managing rules for automatic permissioning
Responsible for recording and editing stored scripts. It's not an extensible backend. It supports Python as scripting language, and tasks / operations are realized by the executor module.
Responsible by managing tasks to be executed by the executor module. It's a non-extensible backend.
Responsible for integrating ITSM / Ticketing / Support systems. It's not extensible.
Check the Videos page.