Hi mperrot,

Self-registration via OIDC is currently supported because it delegates the authentication process to a trusted OIDC provider.

User self-registration without an OIDC provider would require a different approach, such as e-mail validation. This is currently not supported. It would require some end-user UI flow where the user can provide all the info necessary to create an account and follow-up with the flow where a password must be set for the IAM account. Feel free to create an idea for this in the ideation section.

When the e-mail address is known, you could set up the accounts in IAM in advance as well and guide them to the reset-password flow.

Alternatively, you could provide a custom registration website with a server-sided component that provisions the user in IAM.

Last option would be to use a regular Thinkwise application for self-registration and inject a service account to allow access to this application. I’ve seen it done but it does have some security and deployment implications.

@mperrott how about using OpenID with Microsoft with any of the other values? https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#find-your-apps-openid-configuration-document-uri
 

• If other companies in your group use Azure AD as well, you could specify per tenant (similar to your current setup)
• If other companies in your group use Azure AD, but you don’t know these org’s details, you could use organization
• If users should (also) be able to use their personal account you could use consumer or common —> I believe this also works for users that register their Google account (f.e) with Microsoft, but of course you could then also setup OpenID with both Microsoft consumer and Google

Good Day @Anne Buit,

I believe what would be nice to have is the User self-registration with an email validation to make it work as I describe. I will raise an idea for it.

The problem here is that emails are not known. It could be anyone. The fact is the latter part of what i describe as the flow in the application is when Approved Candidates are moved to main System, we are already doing it Manually. We have scripts that creates the Approved Applicant into IAM and that is because we have their data and email and we can send to IAM for registration. Here we want to automate all this process by not having to place anything manualy into Main system.

Your Last comment also maybe is a good idea for a solution that we allow login with service account (Registration) and automatically to have a process flow with task executing to allow user to enter basic mandatory information for creating an account with us. Once that executed we register them in IAM forcing them to have password and email in the login. Since they will have an account and are registered in IAM they continue filling in their profile and necessary information with their account. If they are Approved then we move them to main system for internal processing and hiring.

Hi @Arie V ,
Good day also,

We are already using it for our organization so we have it setup as per point 2 above. What we tried and failed is the 3rd one but need to recheck it. Our problem here is that we do not know if they are registered with any of the main players (Microsoft, Google etc...) for OPENID… So I believe if we had the Email verification for provisioning Accounts in IAM it would be useful, but also the Idea from Anne is also something hacky but doable. 

Thank you both.

@mperrott following up on this suggestion from @Anne Buit: how about the Azure Self-service sign-up flow that you could optionally combine with Google / Facebook / personal Microsoft accounts, but all working through the Open ID registration between Thinkwise and the Azure AD tenant you have already configured? https://learn.microsoft.com/en-us/azure/active-directory/external-identities/self-service-sign-up-user-flow
 

Hi @Arie V ,

Will test that out, so I will not mark a best answer yet.

I will report back as soon as I have some results of what is doable.

thank you for your suggestions. Much appreciated.

thank you

Mike

@mperrott did you manage to test the options given here and did any work out for you? If so please tag an answer as best answer.

@mperrott what solution did you end up with?

We did an interesting trial in the meantime and will move forward with this solution for our fleet (note: this involves us knowing an email address of the user):

As soon as a Crew member is planned on a Vessel, we do the following (simplified flow):

1. Create an IAM User record
2. Add User to relevant IAM User Group
3. Create Azure AD Guest user invite (B2B Collaboration) through Graph API
4. Send custom Invite email to the email account from Thinkwise application

Microsoft personal was by default setup as Identity provider in our Azure AD Tenant. We also added Google as Identity Provider in our Azure AD (https://learn.microsoft.com/en-us/entra/external-id/google-federation).

As a result, our end users can use their known email account and will experience the following login flow, depending on account:

1. If Microsoft personal (outlook/hotmail/live/msn): redirect from Universal to Microsoft login > add email + password > redirect back to Universal as signed in User
2. If Google: redirect from Universal to Microsoft login > add email > redirect to Google > add password > redirect back to Universal as signed in User
3. If Other (all other domains): redirect from Universal to Microsoft login > add email > Microsoft recognizes account doesn’t exist at Microsoft personal and guides user to set password and register account with Microsoft > redirect back to Universal as signed in User