{"action":"opened","issue":{"url":"https://api.github.com/repos/joscha/play-authenticate/issues/358","repository_url":"https://api.github.com/repos/joscha/play-authenticate","labels_url":"https://api.github.com/repos/joscha/play-authenticate/issues/358/labels{/name}","comments_url":"https://api.github.com/repos/joscha/play-authenticate/issues/358/comments","events_url":"https://api.github.com/repos/joscha/play-authenticate/issues/358/events","html_url":"https://github.com/joscha/play-authenticate/issues/358","id":343375680,"node_id":"MDU6SXNzdWUzNDMzNzU2ODA=","number":358,"title":"Opposite of merging users?","user":{"login":"EvertHoff","id":13462984,"node_id":"MDQ6VXNlcjEzNDYyOTg0","avatar_url":"https://avatars1.githubusercontent.com/u/13462984?v=4","gravatar_id":"","url":"https://api.github.com/users/EvertHoff","html_url":"https://github.com/EvertHoff","followers_url":"https://api.github.com/users/EvertHoff/followers","following_url":"https://api.github.com/users/EvertHoff/following{/other_user}","gists_url":"https://api.github.com/users/EvertHoff/gists{/gist_id}","starred_url":"https://api.github.com/users/EvertHoff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EvertHoff/subscriptions","organizations_url":"https://api.github.com/users/EvertHoff/orgs","repos_url":"https://api.github.com/users/EvertHoff/repos","events_url":"https://api.github.com/users/EvertHoff/events{/privacy}","received_events_url":"https://api.github.com/users/EvertHoff/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-07-22T04:21:56Z","updated_at":"2018-07-22T04:21:56Z","closed_at":null,"author_association":"NONE","body":"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...\r\n\r\nLet'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.\r\n\r\nAfter 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.\r\n\r\nSo, 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.\r\n\r\nIt might work as follows: \r\n\r\nMy 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.\r\n\r\nMy 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. \r\n\r\nOnce all users have migrated, OneLogin could be made the only allowed authentication provider for this account.\r\n\r\nPlease let me know your thoughts on how to best handle such a scenario.\r\n\r\nThanks,\r\nEvert\r\n\r\n"}}
{"actor":{"display_login":"EvertHoff"}}