Identity Providers

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.

It can be configured to accept one single provider in a first accepted authentication mode, or to required all providers to be authenticated to allow the user.

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.

QuidgestIdentityProvider

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.

OpenIdConnectIdentityProvider

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.

CMD Government Authentication (Portugal)

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.

You test environment endpoints should look something like:

• Authority = https://preprod.autenticacao.gov.pt/OAuth/AskAuthorization
• DataAPI = https://preprod.autenticacao.gov.pt/OAuthResourceServer/Api/Resource
• UserFieldId = http://interop.gov.pt/MDC/Cidadao/NIF

This provider currently only works with Portuguese authority.

CASIdentityProvider

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>

For the WebAdmin configuration:

• Authority = Your CAS base path, usually something like https://hostname/cas
• AttribValidation = 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.

LDAPIdentityProvider

LDAPQueryIdentityProvider

TOTPIdentityProvider

WebAuthIdentityProvider