We are constantly expanding our Identity Broker with powerful new features. Discover the features & specifications here.
The Connectis Identity Broker’s Dynamic LoA functionality brings down the log-in threshold for your customers. After logging in once using a high-assurance method, the user is given the option of allowing installation of a cookie on their device. If they allow the cookie, they can use a lower-level method for subsequent log-ins, because the cookie acts as a second authentication factor. Of course, the cookie can do that only after a log-in method with a high assurance level has been used once. As the service provider, you can define the cookie’s validity period. Dynamic LoA works with all IdPs and all assurance levels.
Configurable cancel flow
You, the service provider, can decide what happens when a user opts to cancel part-way through logging in with a given IdP. You might want the user prompted to choose an alternative IdP, for example. Or you might want them returned to the page within your application where the authentication process started.
As a service provider who supports multiple eIDs, you want consistent log-in information from the supported systems. However, different eID systems use different names for their assurance levels, For example, the SAML standard refers to ‘Smartcard’ where eIDAS uses ‘Substantial’ and eHerkenning uses ‘LoA300’. The Connectis Identity Broker’s LoA Mapping functionality solves that problem by translating the information into a single ‘language’. You, the service provider, decide what each assurance level will be called in the CIB response messages you receive.
Registry Attribute Enrichment
During the authentication process, the Connectis Identity Broker can consult external data sources to obtain and communicate additional user attributes. External sources it can interface with include the Dutch Chamber of Commerce, the Individual Health Care Professions Register (BIG), the National Personal Records Database (BRP), and the National Register of Addresses and Buildings (BAG). The service provider needs to be authorised to access some external data sources.
With the Connectis Attribute Provider, an authentication response can be enriched with any additional attribute you wish. As a service provider, you can record additional user attributes in the Connectis Attribute Provider, such as information given during the onboarding process. The Connectis Identity Broker can then supply the appropriate attributes with each subsequent authentication. The Connectis Attribute Provider is always deployed when you enable Account Linking, MyOwnIdP, 2FA or SSO.
As a service provider who supports multiple eIDs, you want consistent log-in information from the supported systems. That can be tricky, because not every system uses the same name for a given attribute: one may refer to ’email’ and another to ’emailaddress’, for example. The Connectis Identity Broker’s Attribute Mapping functionality solves that problem by translating the information into a single ‘language’. You, the service provider, decide what each attribute will be called in the CIB response messages you receive.
Every screen that the Connectis Identity Broker shows to a user following log-in can be customised to reflect your corporate style, so that the user has a sense of continuity.
Universal IdP support
In principle, the Connectis Identity Broker can interface with any Identity Provider/eID system. The only condition is that the CIB supports the protocol used by the system in question. Any system that adheres to the basic SAML protocol presents no problem. If a system departs from the protocol, it’s necessary to find out whether the non-standard aspects are already supported, or whether adaptation is required. Interfacing with an eID system involves uploading the metadata, then configuring the IdP and protocol options in the CIB.
With the Connectis Identity Broker, you can enable single sign-on (SSO) for any supported IdP, including those that don’t themselves support SSO. To make that possible, the CIB retains the authentication data and gives the service provider a unique, non-identifiable key for recognising the user. Any of the service provider’s other applications that have the same key can then authenticate the user without having to refer to the IdP. Naturally, the CIB checks whether the appropriate assurance level is met and whether the requested attributes are available. A decision can then be made as to whether the user can continue as part of the same session, or requires (further) authentication with an IdP. This functionality requires the use of the Connectis Attribute Provider.
The CIB’s IdP filtering capability means that users are offered only those IdPs that meet the appropriate assurance level and can supply the required attributes.
The Connectis Identity Broker can decrypt attributes for you, so that you don’t need to implement your own decryption. The feature works with both SAML encryption and the polymorphic encryption used in eHerkenning and eIDAS.
With IdP scoping, a user can be directed straight from the service provider’s application to a particular IdP, without the user being offered multiple IdPs to choose from within the Connectis Identity Broker. That enables you to let the user make a choice within your application, or to enforce the use of a given IdP for a given service, for example.