Skip to main content

Roadmap to integrate cidaas

cidaas roadmap

Table of Contents

  1. Planning Your Integration
  2. GO-live Strategies
  3. Data Migration
  4. Application Integration
  5. System Landscape Integration

Planning Your Integration

cidaas can be integrated into almost any system landscape. Integration can be done independently, with our support, or together with one of our partners. In addition to supporting the standards OAuth2, OIDC, SAML, and Kantara, we follow the everything is an API approach.

After deciding to use cidaas, you'll need to answer these key questions:

  • What should the GO-live process look like?
  • Which systems do you want to connect to cidaas initially versus after GO-live?
  • Do you need to migrate existing data?
  • How should authentication be displayed to customers?
  • Which data needs to be shared with other systems?

Integration Categories

These questions impact four main categories:

  • Data migration
  • Application integration
  • Backend system integration
  • GO-live execution

GO-live Strategies

Migration Approaches

Step-by-step Migration Migrate applications one at a time, requiring synchronization between systems.

Benefits:

  • Smaller, manageable GO-live packages
  • Extended planning time for system adaptations
  • Reduced risk by focusing on one application
  • Easier rollback if issues occur

All-in-one Migration Migrate all applications simultaneously, eliminating synchronization needs.

Benefits:

  • No dependency on legacy systems
  • Reduced maintenance and operational effort
  • No complex synchronization architecture
  • Immediate system-wide benefits

Migration Scale Examples

ScaleUsersUsageModeKey Considerations
Small5008h/5dAll-in-oneWeekend migration possible
Medium10,00024/7All-in-oneRequires long-term sync
Large40M+24/7Step-by-stepPermanent synchronization needed

Data Migration

If you start on a greenfield you could skip this section ;)

Data migration mostly means user migration, but if you migrate from another oauth/OIDC solution also app-settings could be interesting. Do you have an existing consent-management? Should consents be migrated as well? Do you want that users remain logged in -> Migration of tokens and session?

At this point we guess you have an answer for question 3. That automatically leads to the question How to migrate data to cidaas, we suggest 3 different ways to migrate depending on

  • Amount of data
  • GO-live approach - all-in-one or step-by-step
  • expected downtime during GO-live

Our suggestions are based on our experiences and use cases in past. You are open to follow other suggestion or define a best match together with us or a partner.

Application Integration

Connecting your applications to cidaas is based on OIDC and oauth. We provide different SDKs and plugins to make the integration as simple as possible - you can find them in GitHub.

To find the best flow for your application, we recommend using following overview.

oauth oidc

We describe the flows in detail in our documentation

  • PKCE
  • Device Code Flow
  • Client credentials

Other flows which are mentioned in OIDC and oauth are possible and maybe needed for third party systems, but wherever it is possible we recommend using one of the 3 above mentioned.

If you newly integrate an oauth/oidc based CIAM, you will also have some changes for login and registration. One part is to separate login-forms from the business application to a standalone approach. In cidaas we call it hosted pages.

In this section we will focus on question 4 How should authentification display to the customer?. cidaas provides a default set on hosted pages which can be customized up to a certain level. Logo, appname, colors, background and some more can be changed via configuration. Changes beyond that can be implemented and hosted by your own; gladly also based on our template.

Hosted pages include around 20 pages for login, registration, password forgotten, progressive registration, mfa and much more. Depending on the behavior in the system cidaas calls the corresponding page. With progressive registration your app prompts the user for basic information on the registration page. If another app requests more information additional information page will show and gather more data from the users.

default login page

In our Best Practices chapter we created an entry for conception of hosted pages. Before you start to implement or configure the hosted pages you have to decide some important things like what is your username? or do you want to have passwordless authentification?.

It is also possible to create multiple hosted pages to have different look and feel for each touchpoint.

Separation of business applications and login forms increases the security of the entire project and reduces maintenance and customization costs, as the same hosted pages can be used for multiple touchpoints.

System Landscape Integration

As mentioned in Integrate cidaas into your business there are multiple systems which can be connected to cidaas - CRM system, marketing tool, reporting tools or backend APIs - Therefore the last question we listed above is Which data needs to be shared to other systems?.

With the approach everything is an API the connection to cidaas is easy and as flexible as possible. To the other direction cidaas provides around 100 events, which could happen in the system like invite user, but also events for configuration changes like app modified.

backend integration

Just have a look to different types of systems and they could integrate/connect.

Application specific backends

With OIDC and oauth you should not only secure the access to your portals, but also the permissions against your backend. With scopes and roles you can manage access to business data in a very fine-grained way and gain a high level of security.

To integrate the token check in your backend we provide a list of interceptors or you use the in-house functions of specific technologies like in spring

Customer Relationship Management

The best way to connect to a CRM system is to use webhooks. Mostly a wrapper service is needed to map data to the data-model of the CRM, switch to SOAP APIs or others.

In cidaas admin UI you are able to configure multiple endpoints to multiple events. For sure the endpoints should be secured as well, we suggest to use oauth for this, but you could also use an API-key. Go to settings -> Webhook -> Create Webhook

Webhook Management

webhook conf

Marketing Tools

Marketing Tools like Salesforce Marketing Cloud or Emarsys are used to make marketing campaigns, maintain communication templates and more. It makes sense to reuse these systems and connect them to cidaas, too. see RestAPI Provider

The cidaas consent management could also be used for newsletter consents, which be transferred to the marketing tool. This consents could be shown in the user profile and can be updated by the end user.

To change the communication provider in cidaas you first have to create one. Go to settings -> Communication Provider -> E-Mail -> Add new E-Mail Provider. Afterwards you need to select this provider in your templates. Besides REST you could also configure SMTP or others.

provider conf

Reporting Tools

cidaas provides a huge bunch of different reports, but often there are little differences to the needs of all our customers, so that we cannot meet all of them. We suggest filling a reporting tool with all interesting data and create your own filters and views.