Skip to content
This repository has been archived by the owner on Feb 10, 2021. It is now read-only.

Opposite of merging users? #358

Open
EvertHoff opened this issue Jul 22, 2018 · 0 comments
Open

Opposite of merging users? #358

EvertHoff opened this issue Jul 22, 2018 · 0 comments

Comments

@EvertHoff
Copy link

Please let me know if play-authenticate already supports the scenario below. If it doesn't already support it and you don't foresee adding this functionality, please give me some tips on what might be the best way to adapt the architecture of play-authenticate to add this functionality...

Let's say I create a site with play-authenticate where users can create content. A new user starts out by creating a free account and authenticating with LinkedIn. The content that the user has created is intended for the large corporation that they work for. The first user might invite a few colleagues to also help build up this content, each authenticating with LinkedIn, Facebook, etc.

After a while they decide that they like my site and want to buy a premium membership to the site for the large corporation. However, the corporation doesn't want them to authenticate with social media, but instead wants these users to authenticate with the corporation's preferred authentication provider, let's say OneLogin.

So, they don't want to lose the content that they already created and need to find a way to migrate the users to new users that are only authenticated with OneLogin. They want new users to be created in my site that replace the old users, because they want users who are only authenticated by OneLogin so that they can easily revoke authentication for a user if the user leaves the employment of their company. So, it is sort of the opposite of merging users.

It might work as follows:

My site lets each account specify one or more allowed authentication providers for viewing or editing the content owned by that account. The initial user adds OneLogin as another allowed authentication provider for their account and sets it up with a secret and other details for their corporation. Thus, OneLogin is not set up with just one client ID and client secret for my entire site, but with a different client ID and client secret for each account in my site.

My site then sends an email to each of the existing users associated with this account. Each user clicks a link in the email and then authenticates with both authentication providers. My site then creates a new user who only has OneLogin as authentication provider and replaces references to the old user in the content of the site with the new user.

Once all users have migrated, OneLogin could be made the only allowed authentication provider for this account.

Please let me know your thoughts on how to best handle such a scenario.

Thanks,
Evert

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant