Product's handbook¶

Sequel's security services offers a central place to manage authentication and authorization concerns for different applications. The concept of application is key for the security services as most of the configuration is structured around this concept. This configuration can be done using the Security Rest API, the Security Administration website or the sequel security tool.

Authentication and Authorization¶

• Authentication (AuthN) is the process of verifying who you are. When you log on to a system with a user name and password you are authenticating.
• Authorization (AuthZ) is the process of verifying what you can do. Gaining access to a resource because the permissions configured on it allow you access is authorization.

Sequel's authentication implementation is based on the emerging leading standard for single sign-on and identity provision on the Internet: OpenIdConnect; this is explained with more detail at authentication article. The authorization implementation is a role based access control (RBAC) system designed by Sequel, it is wider described in authorization article.

Definition of Application¶

Represents each application registered in the system for providing security, with all its configurations related to authentication and authorization. In terms of Identity Server terminology, an application could be considered a resource. An application is each principal module we can decompose Sequel's suit, e.g. API gateway, Claims, Origin, Rulebook, Impact, RE, Product Builder, Workflow, Rating Engine, Security Management (itself),... For us, an application is a product or a service part of a bigger system.

An application is defined by two properties:

Applications are not editable from API or user import process. However, the application is the central place for managing the configuration:

Application keys¶

All applications needs a Key that must be unique and short in the sequel ecosystem. In order to avoid collisions between different applications we will enforce a naming convention. The current application key assignation is displayed below (in bold are keys in use and in italic are reserved ones for future):

Also, all objects managed by security that are defined in the boundaries of an application (groups, roles, clients, resources,...) must define the Key following this pattern:

ApplicationKey + "." + Code

Where Code is the identifier of each instance of this type of object.

Audit logs¶

Most of the models used in authentication and authorization schemas are auditable storing the information at:

• Last UpdateUser and UpdateDate in the affected record.
• Detailed track of changes in update and delete actions at [authentication].[AuditLog] and [authorization].[AuditLog].