RDM Integration patterns
The methods in the API can be freely combined. Here you find some typical integration patterns:Onboard users (The application sends the eMail)
The "clientExtId" is a unique identifier for your eIAM access client and will be provided to you.To onboard a user, you need to do the following steps:
Step 1: Create user with POST /clients/{clientExtId}/users, you will get back an user object, containing also the "userExtId".
Step 2: Trigger onboarding using POST /clients/{clientExtId}/users/{userExtId}/onboarding, here it is important to set "onBoardingType" to MANUAL.
Request:
Response:
Step 3: You need to take the onboarding code from the response and put it into your onboarding letter you send to the person you want to onboard. Along with this you also must provide the onboarding landing page to the person.
Step 4: Some time later the person will register it's CH-LOGIN and will hit the landing page, where the person will provide the onboarding code.
Step 5: The eIAM access client user will now be linked with the CH-LOGIN and could be used within this access client. Typically the person would access an application where then one or other form of access request (Link: eIAM Access Request (ARQ) ) will happen.
In standard integration the "userExtId" will the subject of the SAML / OIDC Token, so you can match the onboarded user on each login.
Onboard users (eIAM sends the eMail)
The "clientExtId" is a unique identifier for your eIAM access client and will be provided to you.To onboard a user, you need to do the following steps:
Step 1: Create user with POST /clients/{clientExtId}/users, you will get back an user object, containing also the "userExtId".
Step 2: Trigger onboarding using POST /clients/{clientExtId}/users/{userExtId}/onboarding, here it is important to set "onBoardingType" to EMAIL.
Request:
Response:
Step 3: The application don't need to process the response (unless it's an error). eIAM will send an onboarding eMail to the person. The eMail can be templated in the Admin Portal of Delegated Management.
Step 4: Some time later the person will register it's CH-LOGIN and will hit the landing page, where the person will provide the onboarding code.
Step 5: The eIAM access client user will now be linked with the CH-LOGIN and could be used within this access client. Typically the person would access an application where then one or other form of access request (Link: eIAM Access Request (ARQ) ) will happen.
In standard integration the "userExtId" will the subject of the SAML / OIDC Token, so you can match the onboarded user on each login.
Get the state of a running Onboarding
To get the state of a running Onboarding you will just use:
As anwser you will get:
Please note, that the "onBoardingCode" is not present, because eIAM only stores a hashed form of the "onBoardingCode". If the "onBoardingCode" is lost, a new Onboarding must be started.
Manage users
This is classical REST, where you could use GET, POST, PUT, DELETE to fully manager user data itself.Manage access of users
Step 1: Create enterprise roles in the Admin Portal.Step 2: From your application search the the user with GET /clients/{clientExtId}/users
Step 3: assign / revoke a certain enterprise role by using POST /clients/{clientExtId}/users/{userExtId}/entroles or DELETE /clients/{clientExtId}/users/{userExtId}/entroles/{assignmentExtId}