- Description
- How to use it
- Security-Hub Features
- REST APIs
- SDKs
- Angular Management UI
- Delivered In Docker Containers
- Authentication
- OpenEdge PASOE Integration
- Secure Secret Storage
- Dynamic Credentials
- Encryption
- Leasing And Renewal
- Token And Secret Revocation
- Groups
- Policies
- Sealed by default
- Password Generator
- Security-Hub Application Roles
- High Availability
- Use Cases
- API Docs
- Further Reading
Description
Security-Hub is a system for
- Authentication and Entity identity management
- Token management
- Policies / ACLs
- Securely managing and accessing secrets
- Encryption & Decryption as a service
- Secure server logins
- Dynamic credentials for services like AWS and Azure
Security-Hub is an API based application. All features of the Security-Hub application are built using these APIs, which are also available for application developers and integrators to use when integrating their applications to consume Security-Hub services.
Security-Hub is built to do the heavy lifting when it comes to the complexity of integration with external authentication services, secrets and token management, encryption and decryption of data and more.
A key feature of Security-Hub is issuing and managing tokens for authenticated users sessions. These tokens can be used as a global “session token” across multiple components of the modern applications, allowing a user to login to all parts of an application through a single point of access.
The API based application and container based deployment model makes it easy to use Security-Hub with multiple applications. Security-Hub can either be used a built-in component of one application, or implemented as a central security service that can be used by multiple applications, centralizing the setup, access and management of key security features for a business.
How to use it
Security-Hub Features
REST APIs
Security-Hub has a full set of REST APIs for accessing and consuming the full feature set of Security-Hub. This means that the systems features can be accessed from any REST capable systems.
All of the APIs are exposed and documented with the Swagger OpenApi specification.
SDKs
SDKs and code samples are available for some languages and technologies to facilitate getting started.
SDKs are available for easy integration with Security-Hub for Angular front-end developers and Progress OpenEdge developers. Support for other languages that can consume REST APis , such as JavaScript is also easy to do using the SDKs as a reference.
Angular Management UI
Security-Hub has a modern Angular management interface, written using the Security-Hub SDK and APIs that are also available to customers for application integration. All of the features in the management UI can also be accessed from custom applications or other tools that support REST APIs.
Delivered In Docker Containers
Security-Hub is delivered with containers and can be installed on all Docker container compatible platforms.
Standard deployment options include Docker Compose and Kubernetes Helm Charts.
Authentication
Security-Hub is built to provide seamless integration with multiple authentication backends. Supported authentication services are currently:
- username and password
- LDAP / Active Directory
- Kerberos for true SSO on windows and linux clients
- OIDC (Azure AD and Office 365, Google and more) This authentication service provides access to a wide range of backend authentication sources.
Additional services are on the roadmap to be implemented when needed by customers.
securable can authenticate a user in a number of ways, such as username/password, Active Directory, TLS certificates and Radius. Security-Hub users can be associated with more than one backend authentication account.
A user’s “identity” and credentials are used when logging into Security-Hub. Security-Hub then handles the backend authentication to validate the user, checks the user’s permissions, group and policy membership after which a session token is issued to indicate the user is successfully authenticated.
Tokens can be used as a global session identifier across multiple applications and can be used by applications to access further features in Security-Hub.
OpenEdge PASOE Integration
Security-Hub works with OpenEdge PASOE (application server) to provide a single point of configuration for authenticating and authorizing access to applications. OpenEdge PASOE uses Security-Hub as an OAuth2 authentication source, through which all of the other configured authentication sources are then available.
For Progress OpenEdge application developers working with PASOE, the integration support makes it easy to secure PASOE applications without the need to build and maintain features like user tables, group and policy memberships, access control lists, custom integration points, and managing account details. All key features for all applications, but not core competencies for most application developers.
Authenticated user session tokens can be used by the backend applications to access additional features in Security-Hub such as policies, ACLs, secrets and tokens, encryption of data and password generation.
Templates for PASOE configuration files can also be stored in Security-Hub. This makes it possible to manage pre-defined configurations for different types of setups or versions of the application. Templates can easily be retrieved from Security-Hub with an authenticated API call, making it possible to automate the retrieval and use of these files.
Secure Secret Storage
Arbitrary key/value secrets can be stored in Security-Hub. These are encrypted prior to writing them to persistent storage. So gaining access to the raw storage isn’t enough to access your secrets. They can only be accessed after an authenticated login.
Secrets can be any form of sensitive information, such as API keys, passwords, certificates, SSL keys, encryption keys, etc.
Secrets are created and managed in a “tree of secrets” with policies and permissions applied to them, allowing for the management of access to secrets by individual users or groups of users.
Dynamic Credentials
Security-Hub can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it makes an API call to Security-Hub for credentials, and Security-Hub will generate an AWS keypair with valid permissions (single- or multiple use) on demand. After creating these dynamic secrets, Security-Hub will also automatically revoke them after the lease is up.
Using Dynamics Credentials, there is no need to give any users “root” access to external systems that support this. Generated credentials can also differ based on user policies and are only generated when needed, so there is no need to store copies of these anywhere once they have been used.
Encryption
Security-Hub can encrypt and decrypt data without storing it. This allows security teams to define encryption parameters and developers to store encrypted data in a location such as SQL without having to design their own encryption methods.
Leasing And Renewal
All secrets in Security-Hub have a lease associated with them. At the end of the lease, Security-Hub will automatically revoke that secret. Clients are able to renew leases via built-in renew APIs.
Token And Secret Revocation
Security-Hub has built-in support for token and secret revocation. Security-Hub can revoke not only single secrets, but a tree of secrets. For example all secrets read by a specific user, or all secrets of a particular type.
Revocation assists in key rolling as well as locking down systems in the case of an intrusion.
Groups
In addition to the entities (users) maintained in Security-Hub, these users can be associated with Groups.
Policies
Groups can in turn be associated with one or more policies that determine the feature set in Security-Hub that users have access to. Policies are a collection of rules with associated capabilities that determine the access levels to Security-Hub features.
These policies can also be used to configure ACLs (Access Control Lists) with supporting APis that can be used by applications to read and apply access to internal application features - without the need for configuring and maintaining this in the application databases.
Sealed by default
A Security-Hub system is sealed by default when it is created or if it is shut down and restarted. A combination of sharded keys are needed to unseal the system before it can be used. These keys are generated at system initialization, and must be kept safe (preferably with keys distributed to separate stakeholders) as they cannot be re-created or retrieved if lost. Lost keys will result in a sealed and completely inaccessible system.
Security-Hub facilitates the process of initializing, sealing and unsealing a system through the use of the management UI or available APIs.
Password Generator
Security-Hub includes an integrated password generator that can be used from the management ui or called from an API. This allows application developers to use Security-Hub as an integration point to generate (and if needed, store) highly secure passwords.
Security-Hub Application Roles
Security-Hub supports the ability for applications to request credentials to login to securable and get a token that can be used to subsequently access features such as OIDC tokens, Dynamic Secrets which can in turn be used to access other external systems.
An example of this could be an OpenEdge PASOE application server that requests single-use credentials from Security-Hub to log on and perform an action on an AWS system. The only required information needed for the application server is the application role id and the Security-Hub endpoint to communicate with. Security-Hub validates the calling application (e.g. by the id and the IP address) and in a highly secure workflow sends the required credentials to the caller on a pre-defined callback endpoint. The generated credentials have very limited access in Security-Hub and can only be used for selected features. In this way, applications can gain secure access to external resources without the need for storing sensitive credentials anywhere.
Security-Hub application roles is an enterprise feature and is available on special request.
High Availability
A standard installation of Security-Hub is deployed as a single instance of the database and vault secure storage. The Security-Hub architecture is designed so that it can be extended to support high availability (HA) deployments with multiple replicated instances of the core application components. This provides better availability and security for the data stored in Security-Hub.
Security-Hub HA is an enterprise feature and is available on special request.
Use Cases
API Docs
Security-Hub Swagger API docs (build.one)
Further Reading
Sample oeablSecurityJWT.csv file
Back to 
Documentation
Back to Home Page