OpenID Connect (OIDC) is an authentication protocol built on top of the OAuth 2.0 framework. It is designed to provide a standardized and secure way for applications to perform user authentication. OIDC enables clients (such as the New Phoenix Application) to verify the identity of end-users based on authentication performed by an authorization server.Key features of OIDC include the use of identity tokens, which contain information about the authenticated user, and the ability to obtain additional user information through user info endpoints. It also supports Single Sign-On (SSO), allowing users to log in once and access multiple applications without the need to re-enter credentials.
In the context of the Core Banking System (Vanguard Financials), the Vanguard Financials Identity Server likely acts as the OIDC provider (authorization server) responsible for authenticating users and providing identity tokens.These tokens can then be used to securely verify the identity of users and access protected resources. The authentication server comes with its own data source, meaning VanguardFinancialsDB_AuthStore will no longer be used. Instead a new data source VanguardFinancialsDB_IdentityServer will be used to store all user information i.e username,email, password e.t.c
In summary, OpenID Connect is a protocol that enhances OAuth 2.0 by providing a standardized way for applications to authenticate users, obtain user information, and enable Single Sign-On. The Vanguard Financials Identity Server implements this protocol to facilitate secure and standardized user authentication for the phoenix solution. You can read more about OIDC and its protocols here
In order to run the authentication server on your local environment, there are several pre-requisites that should be existing on the environment you are trying to setup . They are listed below
Source Code of the project
.NET Core version 6
SQL Server
Once you have ensured have all the pre-requisites and you have the source code to the project. The authentication server has three components. STS, STSAdmin, STSApi.
This is the main component of the authentication server.
In the context of OpenID Connect (OIDC), an STS (Security Token Service) is a specialized server responsible for issuing security tokens that enable secure communication and authentication between different entities within a system. In our case, using Vanguard Financials Identity Server as the STS, it serves as the OIDC provider or authorization server.
The STS, such as Duende Identity Server, plays a crucial role in the OIDC flow. When a user attempts to log in to a client application (e.g., the Phoenix CBS Applications), the following steps typically occur:
Authentication Request: The client application initiates the authentication process by sending a request to the Vanguard Financials Identity Server.
User Authentication: Vanguard Financials Identity Server authenticates the user based on the configured authentication mechanisms, such as username/password, multi-factor authentication, etc.
Authorization Grant: Upon successful authentication, Vanguard FinancialsIdentity Server issues an authorization grant (e.g., an identity token) to the client application.
Token Exchange: The client application exchanges the authorization grant for access tokens, ID tokens, or other types of tokens that can be used to access protected resources or make authenticated API requests.
User Information: If needed, the client application can make additional requests to the Vanguard Identity Server's user info endpoint to retrieve additional information about the authenticated user.
By acting as the STS, Vanguard Financials Identity Server ensures the security of the authentication process, issues the necessary tokens, and facilitates secure communication between the client application and other services within the system. The use of an STS like Vanguard FinancialsIdentity Server helps centralize and manage authentication and authorization processes, providing a robust and standardized solution for secure user authentication in OIDC-based systems.
This is the second component of the authentication server. In the context of Identity Servers, especially in scenarios involving administration and management of users, roles, and permissions, an "Admin STS" or "Admin Identity Server" typically refers to a Security Token Service (STS) instance that is dedicated to handling administrative tasks related to identity and access management.
Here is a general overview:
User and Role Management: The Admin STS provides a set of interfaces or APIs for administrators to manage users, roles, and other identity-related entities. This could include functionalities like creating or deleting user accounts, assigning roles, resetting passwords, and managing other user attributes.
Authorization and Permissions: Administrators often need to define and manage access control policies within an application or system. The Admin STS might provide features for setting up authorization rules, managing permissions, and assigning roles to users.
Audit and Logging: Security and compliance are critical aspects of identity management. An Admin Identity Server may include features for auditing and logging administrative actions, helping administrators track changes and ensuring accountability.
Configuration and Customization: Admin STS solutions often allow administrators to configure various aspects of the identity and access management system. This could include setting authentication policies, defining custom claims, and configuring other security-related parameters.
Dashboard and Reporting: An Admin Identity Server may provide a web-based dashboard or reporting interface, giving administrators insights into user activities, login attempts, and other relevant metrics.
This is the component that the CBS Phoenix Solution uses to communicate with our authentication server. If we want to view, create, edit users without having access to the admin dashboard we use the STSApi. When we create a new user in the CBS application, the new user is queued for creation in the authentication's sever (Vanguard Financials Identity Server). There is a window service dll that will then do the task of adding that user to the Authentication Server Data Store. The window service will use this component to create the new user.
When you get the source code to the project once you navigate to the src directory you will see the following directories
VanguardFinancialsIdentity.Admin-Contains Source Code to the STSAdmin Project
VanguardFinancialsIdentity.Admin.Api-Contains Source Code to the STSApi Project
VanguardFinancialsIdentity.STS.Identity - Contains Source Code to the STS Project.
OIDC protocol can be overwhelming to understanding. There are certain concepts that you should be able to have an overview of what they are and how they work. This configurations are controlled by the admin dashboard.
A brief summary of terminologies used in the context of OIDC.
In the context of OpenID Connect (OIDC), a "client" refers to a software application or a service that interacts with the OIDC provider (also known as an authorization server) to perform authentication and obtain identity information about end-users. Clients are integral components of the OIDC flow and can take various forms, such as web applications, mobile apps, single-page applications (SPAs), or backend services. In our case the Phoenix CBS Solution is the client.
Grant types define how a client application obtains authorization to access a protected resource. Each grant type represents a different way in which the client can request and obtain the access tokens needed for authentication and resource authorization. There are several different types of grant types. For our case the CBS Solution uses AuthorizationCode.
It is used to specify where the authorization server should send the user after the authentication and authorization process is complete. The Redirect URI is defined by the client during the registration process with the authorization server. Here the user is redirected back to the solution.
Used to convey information about the authentication and identity of a user. It is one of the tokens issued by the Authorization Server as part of the OIDC authentication flow.
The primary purpose of the ID token is to provide the client application with information about the authenticated user. It is not meant to be used for accessing protected resources but rather serves as a lightweight and secure way to convey user identity information to the client.
Scope is a parameter used during the authorization process to specify the level of access and permissions that a client application is requesting from a user. Scopes define what resources or actions the client is allowed to perform on behalf of the user.
Custom scopes can also be defined based on the specific requirements of the application and the authorization server. Scopes play a critical role in controlling the granularity of access and helping users understand the permissions they are granting to client applications.
For example, an authorization request might include scopes like openid profile email to request authentication, basic profile information, and email access. The authorization server responds with tokens (such as ID tokens and access tokens) that correspond to the approved scopes.
This is just an overview more information on terminologies used in OIDC can be found here and what they do and mean.
Initiation by Client: The process begins when the client Phoenix CBS Solution initiates the flow by redirecting the user to the authorization server (Vanguard Financials Identity Server) with a request containing parameters such as client ID, scope, redirect URI, and response type (which is set to "code" for this flow). Read more on what this terms mean here
User Authentication: The user is presented with a login screen by the Vanguard Financials Identity server to enter their credentials and authenticate. Once authenticated, the authorization server seeks the user's consent for the requested permissions.
Authorization Grant: If the user consents, the Vanguard Financials Identity server generates an authorization code and redirects the user back to the client's specified redirect URI along with the authorization code.
Token Request: The client, upon receiving the authorization code, sends a confidential request (including client ID, client secret, authorization code, and redirect URI) directly to the Vanguard Financials Identity server's token endpoint.
Token Issuance: The Vanguard Financials Identity Server validates the request and, if successful, responds with an access token, an ID token, and optionally, a refresh token.
Token Usage: The client can now use the obtained access token to make secure requests to the protected resources (APIs) on behalf of the authenticated user. The ID token may contain user information, and the refresh token can be used to obtain a new access token when the current one expires.
After setting up all the pre-requisites and familiarizing with the folder structure and what the project entails you can proceed to run the authentication server. First and foremost we need to configure all the configuration settings for each project. This settings change per environment basis. The settings configuration will be configured depending on your environemnt.
By default the projects have been setup to run on this ports
Since this is the main component, we need to configure this part. In the project folder (VanguardFinancialsIdentity.STS.Identity) there is an appsettings.json file.
In the STSIdentity we are only concerned with the database connection strings section. This is where you define the connection string of your database connection.
Server- Should be the server name or IP of the server where the SQL Server Instance is running.
Database- Should be the database name of the authentication server. For convention puposes leave it as it is.
Once this connection strings have been setup correctly, once you run the project for the first time the database will be automatically created with their respective tables and data.Will get to this later. The last step is to specify where the STSAdmin project is running on that server/environment. By default it will be set to https://localhost:44303. Change it if your Admin project is running on a different port.
With this steps done you can proceed to change the config settings to the other project.
This project has several configuration files we need to edit first before we proceed.
appsettings.jsonThis file contains the database connection string, the admin configuration which contains configuration settings for the admin dashboard from assets, to the smtp email configurations for sending emails for forget password functionality. For now will just edit the database connection string to point to our database. This connection string should match the one previously described.
identitydata.jsonThis file contains information that you would wish to be inserted into the database table for the first time when you run the migrations. By default it will insert a user into the dbo.Usersthe User created usually has super administrator access. This user is the only who can access the admin dashboard no one else.
Based on the configs above when you run the migration it will go the dbo.Rolestable add a role with the name VanguardFinancialsIdentityRole. Move to the users table create a user by the username admin set the password to pa$$word123and email to devteam@centrino.co.keand assign them the role we just created. It will also proceed and give the user the necessary claims.
identityserverdata.jsonThis configuration contains all clients,identity resources, api scopes and api resources that should be inserted into the respective tables. Will only edit the clients section. This can remain as it is only change it if your STSAdmin project is running on a different port apart from the default of 44303.
Take note the the http scheme should be https. The STSAdmin project can only run under an SSL secure connection.