Errors documentation¶

Intro¶

Excalibur utilizes a user’s smartphone to act as a secure hardware token for any and all authentication and authorization needs inside of an enterprise. It utilizes the user's smartphone to verify authentication factors such as Location, PIN, Fingerprint, Face scan, etc. according to a security policy of a company or given user / users group (the security policy). Thus, Excalibur enables seamless, multi-factor and passwordless authentication.

To discuss Excalibur errors, 3 basic aspects of Excalibur need to be briefly introduced: Components Excalibur consists of, User roles involved in interaction with these components and Actions users can take in Excalibur.

Excalibur Components¶

Server- Provides a persistent network and storage central point, and therefore must be accessible to all components. It also provides a web-based management interface - the Dashboard, as well as WebSDK, which takes care of communication and operations with integration components. The server is usually deployed on-premise.

Token- The Excalibur mobile application utilizes the user’s mobile phone as a hardware security token - therefore in Excalibur, we call the mobile phone the token. It is primarily used to interact with the user - input of authentication factors, viewing of sessions and their history as well as providing remote locking / logout of sessions. Token uses the biometric sensor if available and HW secure element if supported by the phone.

Client- In the context of Excalibur, the client is usually a PC. The client component provides the Excalibur login screen that is displayed on top of the default Operating System login screen / lock screen. This is achieved by utilizing the Excalibur Credential Provider (CP).

Facade- is the component that interacts with the Active Directory (AD) and thus must be installed on at least one AD server. It runs as a system service and interacts with the AD utilizing the Remote Protocol Directory Replication Service (DRS) resp. LDAP as a backup option.

CA- Excalibur Certificate Authority (CA) issues certificates to other Excalibur components. For security reasons, Excalibur provides cloud-based CA as-a-service - so that even if the customer infrastructure is fully compromised the attacker will not gain control over provisioning of new user tokens.

And lastly Company - referring to an organization, in which all the components (Server, Token, Client, Facade) are deployed.

User Roles¶

User- is a person, an end-user who uses Excalibur to Authenticate and Authorize against Company’s Client(s) and integrations, utilizing his/hers personal Token, and if available on a given Client, manage his/hers sessions. User might also Verify his/hers colleagues (if allowed and required), Reset his/hers own authentication factors, as well as expired password on a Client (if applicable). Every user can also log into the Dashboard, where a regular User only sees own account details, Actions and Sessions.  

Manager- additionally to User privileges, Manager can see additional data in the Dashboard related to his/hers account and data of Users he/she manages resp. supervises, and also has a right to remotely terminate their sessions. Manager cannot change security policies (only view them), and also doesn’t have an access to various parts of the Dashboard such as Groups, Roles, Security policies or Audit. Manager is the role which usually verifies more sensitive actions or actions with incidents of his/hers subordinates.

Administrator- additionally to Manager privileges, Administrator has an access to all data available in the Dashboard, as well as a right to change security policies, geofences, groups and other settings to anyone. Administrator is also a person within the Company designated to install and configure Excalibur, as well as responsible for configuration of Company’s environment in accordance with Excalibur requirements. This is the highest user role in Excalibur and the Dashboard.

There are also user roles with specific access privileges in the Dashboard such as the Service Desk operator or Auditor, but they won’t be discussed in the scope of this document.

And lastly Excalibur Support - while not a user role, nor an end-user within the Company, Support refers to a point of contact in Excalibur, which helps a personnel responsible for Excalibur within the Company to fix problems they cannot resolve.

It’s important to note that even the Administrator is unable to modify events history within Excalibur, which includes Actions log, Timeline, Sessions, Incidents, Verifications and Errors as they have been happening.

User Actions¶

From a user perspective, following are the most common actions divided into 2 categories:

Basic Actions¶

Registration¶

User needs to register first to perform any other action in Excalibur. Registration starts on a Client where user clicks “Register” on the Excalibur login screen and proceeds with self-registration following on-screen instructions. During registration, user sets all authentication factors required by the security policy on his/hers Token, which initializes it.

Authentication¶

Authentication or Login is an action based on a direct user intent and the only one in Excalibur which can operate in an online as well as offline mode. User performs his/hers intent by scanning a login QR code from a Client with his/hers Token. The login QR code is dynamically changing - by default Client generates a new one every 15 seconds with 90 seconds validity. Authentication factors are then verified based on the security policy and if it succeeds, in online mode the User is automatically logged into the Client, while in offline mode, the User is presented on his/hers Token with an OTP code, which he/she needs to manually enter on the Client’s Excalibur login screen to log in.

Authorization¶

Authorization or Confirmation action is a push notification based action for example, VPN Login (in which a username needs to be entered) will trigger a push notification for a Token of a User specified by the username. On the Token, the User is asked to confirm given action with the exact specification of what is being confirmed. Authentication factors are then verified based on the security policy and if it succeeds, User’s action is authorized. RADIUS is currently the primary use-case of Authorization.

Tokenless Authentication¶

If a user forgets his/hers Token, or there’s any other reason a user cannot use or doesn’t have his/hers Token at the moment, there’s a backup option to utilize a Tokenless Authentication. In this case, User begins the process on Client’s Excalibur Login screen, selects “Forgotten phone”, inserts his/hers name, PIN and a reason why his/hers Token isn’t available at the moment. If entered name and pin are verified successfully, this request triggers a usual Verification process in which any verifier designated to verify this user based on the security policy, verifies the action either in person or remotely. Based on user’s Security policy, verifiers have the option to select a time interval (once, hour, 8hours, day) on theirs tokens during which the user can login without further verification on a particular computer. For further tokenless login on this computer, User must type username, PIN and give the reason.

Factors Reset¶

Registered users have an option to reset his/hers authentication factors on his/hers Token. Firstly, authentication factors are verified based on the security policy and if it succeeds, User proceeds to set new factors.

Show Password¶

If Company’s security policies allows users to show their current password on token`s screen, than this action is available in account settings for selected Company. Firstly, authentication factors are verified based on the security policy and if it succeeds, User’s  currently active password stored in Active Directory is shown on his token’s screen.

Set Geofence¶

If Company’s security policies allows action Set Geofence on tokens, than users can store their home or temporary locations thru special interactive screen found in application settings. Firstly, user must define locations on screen’s map by manually touching on dedicated location and confirming popup dialog. Next authentication factors are verified based on the security policy and if it succeeds, User defined location is synchronized between all registered companies.

Special Actions¶

Verification¶

In case of verification a User with appropriate privileges, e.g. Manager (Verifier) using his/hers Token confirms another User's (Initiator) identity and action. Verification begins when User triggers an action or incident, which requires Verification based on the security policy. From verifiers perspective, Verification begins either directly by scanning a verification QR code from initiator’s Token, or by receiving a push notification, or via Dashboard. Verification can be configured in the security policy as a required action for any Basic Action or any policy violation - incident. Basic Action’s flow is then modified to accommodate the Verification after the usual authentication factors verification succeeds on the Initiator’s side. If successful, the Verifier is prompted to confirm the action using his/hers authentication factors on his/hers Token. Every security policy change also requires a verification of the change by Administrator.

Terminate Session¶

Some Client implementations enable a session status monitoring as well as a remote termination. When a User decides to terminate a session via Excalibur, he/she is offered two actions: Lock and Logout. User on his/hers Token is prompted to confirm either of the two and upon dialog confirmation, given session on a Client is locked / logged out. Locked session persists User’s environment state on a Client as it was left, and Token keeps it in the sessions list with status “Locked”. Logout terminates a user session, thus all unsaved changes are lost. After logout, given session is cleared from Token’s sessions list and moved to the sessions history. This action doesn’t involve the usual factors verification.

Expired Password Reset¶

If Company’s Active Directory policy requires users to change their password regularly or if Administrator sets that user must change his/hers password on the next login, User will be prompted to do so at the end of the next usual Authentication process on a Client, where User is automatically prompted to enter a current password as well as to set a new one on the Excalibur Login screen. This action alone doesn’t involve the usual factors verification.

TIP: For more information on Excalibur design, topology and technical explanation of its functionality, as well as its components interaction, please refer to the Excalibur Whitepaper.

Errors and Statuses¶

Errors¶

There are various characteristics of every error for consideration such as which User role(s) might be presented with an error and which might be able to resolve it, on which component(s) error originates (Source component) and on which it might be presented to the User (Destination component), as well as for which Action(s) given error occurs. Destination components on which the User can encounter an error are the Token and Client, while the main gateway for errors and logs for the Managers, Administrators and Service desk operator is the Dashboard, with a few exceptions when these errors might occur on their personal Tokens, because they were involved in an administrative action (such as the Verification) they were taking.

Based on how errors might be produced in Excalibur, they could be categorized as follows:

User Action Errors - are triggered by some user action, and usually begin on the Client (integration) or the Token. The Source Component of this error might be any Component involved in the action, and Destination Component is usually the one user had begun the action on.

Administrative Action Errors - are triggered by actions of administrative personnel, mostly performed in the Dashboard, but sometimes also on their Tokens, if their Tokens were involved in the given action (such as Verification) in the first place. The Source Component of this error might be any Component involved in the action, and Destination Component is usually the one administrative personnel used to perform the action on.

Excalibur System Errors - are mainly triggered by an internal functioning of Excalibur Components - their internal actions, interaction with each other as well as an interaction with platforms they run on, networking and other IO operations, also by installation / uninstallation and configuration of these components, and a few can be triggered by some user action. Generally, they are reported to the Server where they are processed and logged to be available for a review by the responsible personnel via Excalibur Dashboard. System Errors are usually non-resolvable by the User, so if they are triggered by some user action, an actual error is always logged on the Server, but might not be propagated in the same form to the User. Lastly, few System Errors might be encountered by Administrators when they install and configure Excalibur components, which are directly presented and explained in these components.

Statuses¶

Besides Errors, there are also Statuses which have an informative character of the application / Action state and are usually triggered by some user action or external circumstances such as networking issues. Because these statuses are fairly common and there are only a few of them, they will be categorized together with errors they might result into in their own section in the beginning.

Document Structure and Denotation¶

In this document, errors will be examined by Actions and their flow in which they can occur, categorized under Excalibur components on which they are presented to a respective user (Destination Components). An emphasis will be given to the most common errors, and errors that can occur in case of multiple actions will be grouped together and generalized in the beginning and subsequently referenced in the document.

All the errors in this document are clearly denoted by the prefix err, while statuses are denoted by the prefix stat. Errors’ and Statuses’ origins - Source components are denoted in a postfix of each error / status title by the name of respective Component in parentheses, specifically: (Server), (Token), (Client), (Facade), (WebSDK).

Example:

err: sample_error (Token)

This example denotes an error named “sample_error” originated from component Token.

For dynamic values, which are inserted by Excalibur based on current Action and its context, placeholders are used in the document. Placeholders are denoted with “{ACTION}” and they are used for generalized errors / statuses that occur with multiple Actions, and later replaced in a context of each Action.

Token Perspective¶

This perspective discusses errors which Destination Component is the User’s Token. Every category / Action further examined under this perspective is denoted by the prefix Token.

Token: General Errors¶

This category groups all the errors that might occur for various Actions but have the same meaning for all of them. Thus, a description of these errors is generalized.

More frequent:

err: request_timeout (Token)¶

err: cancelled (Token)¶

err: company_not_initialized (Token)¶

err: invalid_credentials (Facade)¶

err: policy_failed (Server)¶

err: invalid_qr (Token)¶

Less frequent:

err: outdated_version (Token)¶

err: unknown_user (Token, Server)¶

err: system_error (Server)¶

err: factor_initialization_failed (Server)¶

err: signature_verification_failed (Server)¶

err: missing_signature (Server)¶

err: unknown_intent (Server)¶

err: bad_message (Client)¶

Token: Statuses¶

Statuses describe application state rather than show an error to the User. Statuses might result in errors based on current circumstances. This category groups all the statuses which Destination Component is the User’s Token. They might occur for various Actions but have the same meaning for all of them, thus their description is generalized.

stat: verify¶

stat: otp¶

err: token_offline (Token)¶

err: client_offline (Server)¶

stat: networking¶

err: connectivity (Token)¶

Token: Authentication¶

Authentication is one of the Basic Actions which is based on a User intent of scanning a dynamically changing login QR code from the Client of choice. Its aim is to log in User into any of Company’s supported Clients (integrations), into which the User should have an access after successful multifactor verification.

The same as applicable for all the Basic Actions, Authentication might involve an additional Verification step based on Company security policy. Basic Authentication process could be divided into five phases:

1. Preparation on Token (online, offline)
2. Processing on Server (online)
3. Factors verification (online, offline)
4. Verification against Active Directory (online)
5. Processing on Client / WebSDK (online)

Next section consists of errors which may occur during some phase of authentication process (flow).

Phase 1 - Preparation on Token¶

This phase is initiated by User after scanning Excalibur login QR with his token from the computer's screen or WebSDK component’s login page. QR code is then decoded and it’s content is validated locally on token. Based on data from QR, authentication intent is constructed and send over the network to the server for processing. Immediately after scanning the status screen is displayed on User’s token to show current authentication status, status of factors verification or to show following errors.

err: invalid_qr (Token)¶

err: company_not_initialized (Token)¶

err: request_timeout] (Token)¶

err: outdated_version (Token)¶

stat: networking > err: connectivity (Token)¶

stat: OTP > err: token_offline (Token)¶

Phase 2 - Processing on Server¶

If authentication flow comes into this phase, we can call it from now online login or online authentication, because communication channel between token and server is established and active. All accounts matching and policy verifications are done on the server against online security policies. Most of errors in this section comes from account’s data incosistency or policy verification failures during authentication.

err: unknown_account (Server)¶

err: unknown_user (Token)¶

err: unknown_company_key (Token)¶

err: signature_verification_failed (Server)¶

err: policy_failed (Server)¶

err: system_error (Server)¶

err: unknown_intent (Server)¶

err: missing_signature (Server)¶

Phase 3 - Factors verification¶

During authentication user must verify his identity by providing security factors based on Company security policy. Some factors as PIN or biometry requires some user interaction. In that case, token should show appropriate screen to gather those factors. All factors that needs to be verified are displayed as an icons on indicator at the top of the token’s status screen.   Different icon colours are used to indicate status of that factor (red - failure, green - success). Every failure during this phase causes into error policy_failed besides of state for additional verification.

err: policy_failed (Server, Token)¶

stat: verify¶

Phase 4 - Verification against Active Directory¶

Errors in this section comes from credentials verification on Active Directory component - Facade. Presence of these errors indicates troubles with the user's AD account.

err: invalid_credentials (Facade)¶

err: no_such_user (Facade)¶

err: signature_verification_failed (Facade)¶

Phase 5 - Processing on Client¶

Final phase of authentication is to log in User into their operating system or webservice. Before signing in, status of the client is controlled to check if there is nothing that will block login. In cases of offline authentication, OTP code generated on token is verified and used to login User.

stat: OTP > err: client_offline (Server)¶

err: bad_message (Client)¶

err: cp_not_found (Client)¶

err: bad_login_token (Client)¶

err: bad_token_id (Client)¶

err: pair_error (Client)¶

err: pair_timeout (Client)¶

err: password_decrypt_error (Client)-¶

err: no_cp_response (Client)¶

err: system_locked (Client)¶

err: decrypt_failed (Client)¶

err: already_logged (Client)¶

err: login_failed (Client)¶

err: account_disabled (Client)¶

err: no_ldap_for_domain (Client)¶

err: bad_signature (Client)¶

err: not_supported (Client)¶

err: invalid_data (WebSDK)¶

Err: expired_credentials (Client)¶

Err: static_credentials (Client)¶

Err: ldap_error (Client)¶

Other errors¶

err: no_such_domain¶

err: secret_decrypt_failed (Client)¶

err: unknown_client (Client)¶

Token: Registration¶

Registration is one of the Basic Actions which needs to be done before any other action in Excalibur is available the User. It’s based on a User intent of scanning a registration QR code obtained in a self-registration process. Its aim is to register the User into Excalibur, during which authentication factors required by a security policy are set and User’s Token is initialized.

The same as applicable for all the Basic Actions, Registration might involve an additional Verification step based on Company security policy. Basic Registration process could be divided into three phases:

1. Confirmation and preparation on Token
2. Processing on Server
3. Factors initialization

Phase 1 - Confirmation and preparation on Token¶

err: invalid_qr (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

err: outdated_version (Token)¶

stat: networking > err: connectivity (Token)¶

Phase 2 - Processing on Server¶

err: invitation_invalid (Server)¶

err: unknown_cert (Server)¶

err: signature_verification_failed (Server)¶

err: policy_failed (Server)¶

err: system_error (Server)¶

err: unknown_intent (Server)¶

err: missing_signature (Server)¶

Phase 3 - Factors initialization¶

err: policy_failed (Server)¶

err: factor_initialization_failed (Server)¶

stat: verify¶

Other errors¶

err: unknown_registration (Token)¶

err: invalid_registration (Token)¶

Error: bad_certificate¶

Error: PrivateEncrypt failed!¶

Token: Factors Reset¶

Factors reset is one of the Basic Actions available to Users on their initialized Tokens. This action involves verifying authentication factors and setting the new ones, both based on the security policy. The same as applicable for all the Basic Actions, Factors Reset might involve an additional Verification step based on Company security policy. Basic Factors Reset process could be divided into four phases:

1. Confirmation and preparation on Token
2. Processing on Server
3. Factors verification
4. Factors initialization

Phase 1 - Confirmation and preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

stat: networking > err: connectivity) (Token)¶

Phase 2 - Processing on Server¶

err: signature_verification_failed (Server)¶

err: policy_failed (Server)¶

err: system_error (Server)¶

err: unknown_intent (Server)¶

err: missing_signature (Server)¶

Phase 3 - Factors verification¶

err: policy_failed (Server)¶

stat: verify¶

Phase 4 - Factors initialization¶

err: policy_failed (Server)¶

err: factor_initialization_failed (Server)¶

Token: Show password¶

Show password is one of the Basic Actions available to Users on their initialized Tokens. This action involves verifying authentication factors to show their current password, based on the security policy. The same as applicable for all the Basic Actions, Show password might involve an additional Verification step based on Company security policy. Show password process could be divided into three phases:

1. Preparation on Token
2. Processing on Server
3. Factors verification

Phase 1 - Preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

Phase 2 - Processing on Server¶

err: policy_failed (Server)¶

Phase 3 - Factors verification¶

err: policy_failed (Server)¶

stat: verify¶

Other errors¶

err: expired_credentials (token)¶

err: invalid_credentials (token)¶

err: no_such_domain¶

Token: Set geofence¶

Set geofence is one of the Basic Actions available to Users on their initialized Tokens. This action involves verifying authentication factors to set geofence, based on the security policy. The same as applicable for all the Basic Actions, setting geofence might involve an additional Verification step based on Company security policy. Set geofence process could be divided into three phases:

1. Preparation on Token
2. Processing on Server
3. Factors verification

Phase 1 - Preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

Phase 2 - Processing on Server¶

err: policy_failed (Server)¶

Phase 3 - Factors verification¶

err: policy_failed (Server)¶

stat: verify¶

Other errors¶

err: reached_max_locations (Token)¶

err: insert_failed (Token)¶

err: system_error (Server)¶

Token: Authorization¶

Authorization is one of the Basic Actions in which contrary to the Authentication, User triggers his / hers intent on an Excalibur integration component (e.g. Radius), triggering a push notification for the Token, where after action confirmation, process continues similarly to the Authentication. The same as applicable for all the Basic Actions, Authorization might involve an additional Verification step based on Company security policy. Basic Authorization process could be divided into four phases:

1. Initiation on integration component (e.g. Radius)
2. Confirmation and preparation on Token
3. Processing on Server
4. Factors verification

Phase 1 - Initiation on integration component (e.g. Radius)¶

Phase 2 - Confirmation and preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

stat: networking > err: connectivity (Token)¶

Phase 3 - Processing on Server¶

err: timeout (Server)¶

err: signature_verification_failed (Server)¶

err: policy_failed (Server)¶

err: system_error (Server)¶

err: unknown_intent (Server)¶

err: missing_signature (Server)¶

Phase 4 - Factors verification¶

err: policy_failed (Server)¶

stat: verify¶

err: unknown_client (Client)¶

Token: Verification¶

Verification is one of the Special Actions that might be involved in any Basic Action as an additional step, based on Company security policy. Actions involving Verification first verify user’s own authentication factors and then proceeds with verification of the action by Users superior, who either scans verification QR code from User’s Token or if the supervisor is Manager or Administrator, he / she could verify the User via Dashboard. Verification process could be divided into three phases:

1. Confirmation and preparation on Token
2. Processing on Server
3. Factors verification

Phase 1 - Confirmation and preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

err: cancelled (Token)¶

stat: networking > err: connectivity (Token)¶

Phase 2 - Processing on Server¶

err: unknown_verification (Server)¶

err: failed_verification (Server)¶

err: verified_verification (Server)¶

err: timeouted_verification (Server)¶

err: unknown_user (Server)¶

err: no_verify_privileges (Server)¶

err: signature_verification_failed (Server)¶

err: policy_failed (Server)¶

err: system_error (Server)¶

err: unknown_intent (Server)¶

err: missing_signature (Server)¶

Phase 3 - Factors verification¶

err: policy_failed (Server)¶

stat: verify¶

Token: Terminate Session (Lock, Logout)¶

If the Client / integration component supports sessioning, Excalibur keeps track of a session lifecycle and enables remote Terminate operations - Lock and Logout. Session lifecycle is reported to User’s Token as well as to the Dashboard, where User or his / hers Manager or Administrator can terminate it. Thus, based on its origin, Termination process could be divided into two or three phases:  

1. Preparation on Token (starts here if initiated on Token)
2. Processing on Server (starts here if initiated on the Server)
3. Processing on Client

Phase 1 - Preparation on Token¶

err: company_not_initialized (Token)¶

err: request_timeout (Token)¶

stat: networking > err: connectivity (Token)¶

Phase 2 - Processing on Server¶

err: no_accounts (Server)¶

err: no_session (Server)¶

Phase 3 - Processing on Client¶

err: bad_message (Client)¶

err: account_not_found (Client)¶

Other errors¶

err: app_hang (Token)¶

Token: Errors on Android Platform¶

This is a set of platform-specific errors on Excalibur Android app. These errors originate from operations performed on the Android platform and specifics it incurs.

More frequent:

err: keystore_not_configured (Token)¶

err: fingerprint_detected (Token)¶

Less frequent:

err: keystore_authenticate (Token)¶

err: playservices_resolvable (Token)¶

err: playservices_fatal (Token)¶

err: auto_date_time (Token)¶

Client: Authentication¶

Authentication is one of the Basic Actions which is based on a User intent of scanning a dynamically changing login QR code from the Client of choice. Its aim is to log in User into any of Company’s supported Clients (integrations), into which the User should have an access after successful multifactor verification.The same as applicable for all the Basic Actions, Authentication might involve an additional Verification step based on Company security policy. The special type of authentication is offline authentication, when client or token are disconnected, thus authentication factors cant be verified on  the server. The login is realized with OTP code shown on the token which is rewrited to the client by the user. The following errors may occur on the client side during the authentication process.

err: Client not found (Client)¶

err: wrong_otp (Client)¶

Client: Registration¶

Registration is one of the Basic Actions which needs to be done before any other action in Excalibur is available to the User. It’s based on a User intent of scanning a registration QR code obtained in a self-registration process or invitation email. Its aim is to register the User into Excalibur, during which authentication factors required by a security policy are set and User’s Token is initialized. The same as applicable for all the Basic Actions, Registration might involve an additional Verification step based on Company security policy. The following errors may occur on the client side during the registration process.

err: wrong_logon_name (Client)¶

err: no_such_user(Client)¶

err: invalid_credentials (Client)¶

err: timeout (Client)¶

err: ldap_error (Client)¶

err: sql (Client)¶

err: Please try again later(Client)¶

err: You can't register the account because email attribute is not set (Client)¶

Client: Credentials saving¶

If the password has been changed or expired, Excalibur will prompt the user to create a new password or confirm the already changed password.The following errors may occur on the client side during the password changing or submitting..

err: timeout (Client)¶

err: Passwords does not match (Client)¶

err: The password does not meet the password policy requirements. Check the minimum password length , password complexity and password history requirements (Client)¶

Client: Tokenless login¶

Tokenless login is one of the Basic Actions which is based on a User intent of filling the credentials and reason why the user can not use online login to the Client of choice. Its aim is to log in User into any of Company’s supported Clients (integrations), into which the User should have an access after successful multifactor verification.The same as applicable for all the Basic Actions, Tokenless login might involve an additional Verification step based on Company security policy. The following errors may occur on the client side during the Tokenless login process.

err: wrong_logon_name (Client)¶

err: PIN is incorrect (Client)¶

Other errors¶

Other errors are errors that occur outside of the actions described above and have a direct impact on the functionality of the client.

err: Connection problem (Client)¶

err: CPUI is not loaded (Client)¶

Further materials¶

Excalibur Whitepaper

Excalibur FAQ