Astian has been, like its applications and users, in constant growth, more and more people from all over the world consume our services, each time they request new features, including data synchronization between products and services, and after testing technologies such as Parse Platform, Google Firebase, AppWrite, AWS among others.
As a measure in Astian, a plan was started to make all the processing of user information and data independent, thus avoiding sharing data with external companies and/or organizations, ensuring the privacy and security of our users.
This strategy has been running for some time, it began with the development of our own storage service in the Astian Cloud, later the development of its API, where users can integrate third-party applications, consume data, and much more, but it does More is missing and therefore the implementation of an SSO and an entire unified authentication system.
Architecture of our new structure.
A robust identity solution relies must be build on a solid foundation.
The architecture of Astian is characterized by scalability and flexibility. It is a cloud native design ready to scale out and prepared for future use cases.
A major architectural component is the federation layer. This layer provides single sign-on and token verification capabilities.
The federation layer supports OAuth 2.0, OpenID Connect 1.0 and SAML 2.0.
Astian is not simply a wrapper around a few federation protocols but has abstracted away from individual protocols. Since the core of this layer has abstracted away from these protocols, support for future and legacy protocols can be easily introduced.
How and when to authenticate depends on your organization its policies, user preferences and context.
While historically it was sufficient to authenticate users with username and password verification, nowadays two-factor authentication is the de facto standard. In fact, more and more organizations are moving towards passwordless authentication. For example with FIDO.
Constantly changing requirements demand a flexible authentication framework. The Astian solution allows chaining authentication modules together in order to provide an adaptive authentication experience. Enforcing security controls and providing the best user experience.
Another benefit is that this method allows you to use your own domain names. Without the need for registering extra DNS records.
It is possible to log in with the default login screen, your own UI server or via a popup
Serverless for user scripting
It should be preferred to use out-of-the-box functionalities from off-the-shelf software. But a toolbox should not restrict your organization in providing value to your customers.
Astian allows plugging in scripts into the authentication flow.
Each authentication module maintains its own session storage. This allows differentiating how long each authentication result should get rememebered.
Each module allows configuring wether to remember its result in a session, a cookie, or not at all.
An access token is a JWT. Yet, can still be used as regular OAuth access tokens. You can introspect and revoke these tokens.
Multi-tenancy means that a single deployment of the software and supporting infrastructure serves multiple customers. This easily allows creating new tenants without the need for installing a single software package.
Because of this creating a new tenant comes with zero costs. Only when using a tenant costs slowly rise because of the increased load on the application and database services, and therefore the need for (auto scaling) extra hardware.
What applications will be linked to this architecture?
The first application that will start using this new architecture will be Midori Browser, later they will follow:
- Astian Cloud.
- Astian Albums.
- Midori Mail.
- Astian Spika.
- Astian Camera.
All these implementations will be done progressively to guarantee a correct integration, thus avoiding failures and loss of information.