Identity Providers

Identity and Authorization Providers are systems or services that manage user identities and access permissions within software applications and online platforms. These providers are crucial for digital security, ensuring that only authenticated and authorized users can access resources and perform specific actions within the system. Identity providers handle user management within the system, while authorization providers control permissions and access rights.

Webadmin supports multiple identity providers in order to manage authentication of users. Each one can function in a completely different way and has its own configuration parameters.

During the authentication mode configuration, the user can configure use a single provider or multiple ones, if the option to "Accept on first success" is chosen, the user will continue trying to log in until their authentication is valid. If the 'Reject' option is chosen, the system stops checking other identity providers as soon as authentication fails. It includes: "Accept on first success" and "Reject on first fail." By default, the option is "Accept on first success." There are several types of identity providers, including OpenIDConnection, CMD Government Authentication, Central Authentication Service (CAS), LDAP, TOTP, and WebAuthN.

Each provider uses different types of credentials, so each provider you add can have significant impact on the Logon UI. Some may ask for the traditional Username+Password, while others require external URL navigation or hardware keys to be used.

Quidgest's Identity Providers

BaseIdentityProvider

The simplest one and default provider. Its a simple User+Pass authentication against the user database. Its passwords are save as one-way hashes in the database and are not recoverable.

Application Database Identity

By default, Quidgest includes a pre-defined Identity Provider with the Application Database Identity type. This ensures that users and permissions defined in the User Management section have access to the application.

OpenIdConnect

The is one of the most standard external authentication protocols. It redirects the user to an external login page. It requires application registration in that provider, with the procedures varying between providers.

If your organization does not support the token endpoint then you can leave the Token Endpoint and Secret configurations blank in WebAdmin. This is not a secure way to authenticate and the JWT send back to the application callback, directly from the provider, is vulnerable to interception and spoofing attacks.

Each user needs to associate its account name to the external Id. This means that each user needs a primary provider like QuidgestIdentityProvider to first make that registration in his user profile page.

In alternative, in WebAdmin, you can configure the UserFieldId to a field where the external provider returns an email, and preset each user with that email. Each provider may return this information in a different field.

Azure Entra

  1. Sign in to the Microsoft Entra admin center.
  2. Browse to Identity > Applications > App registrations > > Authentication. Create a new App Registration first, if none exists.
  3. In the App Registration management, go to the Authentication section, and Add a platform.
  4. Choose Web in the type of platform
  5. Add your redirect callbacks according to where you are hosting the application
    1. https://<host>/auth/OpenIdConnectLogin/<id>
    2. https://<host>/auth/OpenIdConnectRegister/<id>
    3. If you are testing you may need to add a few more for your development environment with host = localhost:
    4. <id> is the unique id name you should configure in your provider in webadmin
  6. You should be using Authorization Flow for best security, so in 'Implicit grant and hybrid flows' uncheck the Access Tokens and ID Tokens
    1. You will need a secret for your authorization endpoint, go to the Certificates & secrets section
    2. Create a new Client secret and copy the Value (do this immediately, this value will only be available during creation screen)
  7. Get all the configurations you need to gather, navigate to the Overview section
    1. The Application (client) ID
    2. Click on 'Endpoints' and get 'OAuth 2.0 authorization endpoint (v2)' and 'OAuth 2.0 token endpoint (v2)'

Google

  1. Sign into your Google API Console
  2. Create a new Project in case you don't have one to represent your application
  3. Navigate to 'Credentials' and create a new 'OAuth Client ID'
  4. Setup your Authorized Javascript Origins according to where you are hosting your application
  5. Setup your Redirect URI's according to where you are hosting your application
    1. https://<host>/auth/OpenIdConnectLogin/<id>
    2. https://<host>/auth/OpenIdConnectRegister/<id>
  6. Add a new Secret to your application
  7. Get all the configurations you need
    1. ClientId and Client secret should be available in the previous configuration page
    2. Authorization Endpoint should be documented as https://accounts.google.com/o/oauth2/v2/auth
    3. Token Endpoint should be documented as https://oauth2.googleapis.com/token

These documented endpoints are subjected to future change, so make sure you confirm they are up to date.

Digital Mobile Key - CMD Government Authentication (Portugal)

The Citizen Card in Portugal uses a system called CMD (Citizen Card on Mobile Device), which allows access to public services through mobile devices in a secure and convenient way. CMD is a provider, that is, a provider of digital identification services, which facilitates the interaction of citizens with the government and other entities.

To obtain an access token for the digital identification API system in Portugal, such as the Citizen Card API or any governmental service, you typically need to follow a structured process, which involves registering as a developer and applying for API access. Here are the typical steps you might need to follow:

  1. Registration on the Portal: First, you need to register on the relevant government portal or the entity that offers the API. For example, this can be done through the portal of the Agency for Administrative Modernization (AMA) or another relevant governmental body.
  2. API Access Request: After registering, you generally need to fill out an API access request form. This form may ask for details about how you plan to use the API, the type of data you need access to, and other relevant details about your project or organization.
  3. Acceptance of Terms of Use: You will need to accept the terms of use or the end-user license agreement (EULA), which details the rules and regulations associated with using the API.
  4. Approval of Request: Your request will be reviewed by the government body or entity responsible. This process can take some time, depending on the complexity of the request and the evaluation criteria used.
  5. Receiving the Access Token: Once your request is approved, you will receive an access token. This token is a secret key that you will use to authenticate requests to the API.
  6. Implementation and Testing: With the token, you can start integrating and testing the API in your applications or systems, following the provided technical documentation.

Only after obtaining the API accesses will you be able to configure the identity provider in the webadmin.

This provider is very similar to the OpenIdConnect but the protocol does not follow the same standards. Registration is handled by request on a case by case basis, so the procedure will depend on those communications.

You will need to gather the Client Id, the Authorization Endpoint and the Token information Endpoint. You should then configure the UserIdField you want to fetch from the Token response to match your internal users.

WebAdmin configuration: Your test environment endpoints should look something like:

This provider currently only works with Portuguese authority.

Central Authentication Service (CAS)

The Central Authentication Service (CAS) Identity Provider is a centralized authentication solution used by many institutions to enable a single login (SSO - Single Sign-On) to access multiple services and applications.

This provider connects to Apereo CAS protocol 3.0 to allow SSO authorization flows.

The configuration is highly dependent on version but you need to register your callback function as an authorized CAS service: https://<host>/auth/CAS/<id>

WebAdmin configuration:

  • Authority - IT is the url to use when making CAS calls, your CAS base path, = https://hostname/cas
  • AttribValidation - Attribute from callback returned from CAS Server to validate if user exist, optionally define a different field from username that cas returns in the token validation reply.

For testing its recommended to use the CAS docker image. Instructions for setup are included in the CASIdentityProvider source code.

LDAP

LDAP, which stands for Lightweight Directory Access Protocol, is an open application protocol used for accessing and maintaining distributed directory services over an Internet Protocol (IP) network. LDAP operates on a client-server model, where an LDAP directory server stores all the information in a directory that can be queried and modified by clients. Clients can ask questions to the directory server (for example, searching for a user's email address, authenticating a user against the directory, or obtaining a list of group members) using the LDAP protocol.

There are two types of operations or authentication methods that can be performed:

LDAP Simple

Simple Authentication - This is the most basic authentication method available in LDAP.

  • It is suitable for situations where security is not a critical concern or where the connection can be securely encrypted.

WebAdmin configuration:

  • Domain - Local domain. In the form of 'example.org'
  • Port - Port number of the LDAP service. Leave blank for default. LDAPS usually 636.

LDAP Query

Refers to the execution of specific or filtered queries in the LDAP directory.

  • Queries are made using LDAP filters in conjunction with the search commands of the protocol, which allow specifying exactly what information is needed and how it should be filtered.

WebAdmin configuration:

  • Domain - Query to perform against ldap. In the form of 'cn=username,ou=domain users,dc=example,dc=com'
  • Port - Port number of the LDAP service. Leave blank for default. LDAPS usually 636.

TOTPIdentityProvider

TOTP stands for Time-Based One-Time Password. It is a common method of adding an extra layer of security beyond a standard username and password. TOTP generates a temporary code that changes after a set period of time, usually 30 or 60 seconds.

The second factor is the Time-based One-Time Password (TOTP) provided by an application like Google Authenticator. A 6-digit number provided by the application must be entered during login.

  • Typically, setting up this Identity Provider is only necessary when Two-Factor Authentication is active.

The setup configuration is detailed in the solution guide provided to the user when attempting to change their password.

Configuration:

  1. Install one of the following applications:
    • Google authenticator
    • GoogleMicrosoft authenticator
    • Googleuthy
  2. Use the application to scan the QRCode or manually insert the code displayed.
    • NOTE: The QRCode/code will appears on the displayed page during the password change.
  3. Fill the 6 digit code obtained from the application

WebAuth

WebAuthn (Web Authentication) is a web standard published by the World Wide Web Consortium (W3C) WebAuthn is a core component of the FIDO2 Project under the guidance of the FIDO Alliance. The goal of the project is to standardize an interface for authenticating users to web-based applications and services using public-key cryptography.

Already considered an authentication standard by the W3C

NOTE: Just implemented for MVC applications.