{"action":"created","issue":{"url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/1558","labels_url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/1558/labels{/name}","comments_url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/1558/comments","events_url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/1558/events","html_url":"https://github.com/IdentityServer/IdentityServer3/issues/1558","id":92355251,"number":1558,"title":"Question/Discussion : Single identity with multiple user accounts","user":{"login":"aliozgur","id":799194,"avatar_url":"https://avatars.githubusercontent.com/u/799194?v=3","gravatar_id":"","url":"https://api.github.com/users/aliozgur","html_url":"https://github.com/aliozgur","followers_url":"https://api.github.com/users/aliozgur/followers","following_url":"https://api.github.com/users/aliozgur/following{/other_user}","gists_url":"https://api.github.com/users/aliozgur/gists{/gist_id}","starred_url":"https://api.github.com/users/aliozgur/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/aliozgur/subscriptions","organizations_url":"https://api.github.com/users/aliozgur/orgs","repos_url":"https://api.github.com/users/aliozgur/repos","events_url":"https://api.github.com/users/aliozgur/events{/privacy}","received_events_url":"https://api.github.com/users/aliozgur/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/IdentityServer/IdentityServer3/labels/feature%20idea%20-%20discuss!","name":"feature idea - discuss!","color":"006b75"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":14,"created_at":"2015-07-01T11:21:03Z","updated_at":"2015-08-21T15:05:12Z","closed_at":null,"body":"IdentityServer3 really rocks and the code is fun and pleasure to read.Thank you @brockallen, @leastprivilege and all contributors for such a great implementation.\r\n\r\nRecently we've successfully implemented IdentityServer3 in our university. But there are couple of things that might be improved.\r\n\r\nOur setup is something like this\r\n\r\n* We have an in-house developed Student Information System (SIS) which uses Forms Authentication\r\n* We have more than 15 web applications inside SIS\r\n* We have two AD domains. One for students and another one for academic and administrative staff\r\n* Each student has a single identity on AD but may have multiple student accounts in SIS\r\n* Each staff has a single identity on AD but may have an instructor and staff account in our SIS\r\n* We have an in-house role based access control module. Roles are attached to accounts (actually person records) not identities.\r\n* We use external providers (Google,Twitter, Microsoft and Facebook) for authentication as well. Users can pair their AD domain accounts with external provider accounts.\r\n\r\nFor authentication we use the post fix provided in the username to identify the correct AD the user will be authenticated from. After successful authentication we query our SIS to discover which accounts are paired to the authenticated identity. \r\n\r\nA sample identity/account information\r\n\r\n> Username/Identity : ali@sample.edu\r\n> Undergraduate Student Account Id : 103610059\r\n> Graduate Student Account Id : 108600012\r\n\r\n\r\nOur implementation generates the following claims\r\n\r\n> sub : ali@sample.edu\r\npreferred_username : ali@sample.edu\r\nSisId : Student|103610059|111\r\nSisId : Student|108600012|11111\r\n**Rbac roles for 103610059**\r\nRbacRole : 11|REG|CREATE\r\nRbacRole : 11|REG|READ\r\nRbacRole : 11|REG|DELETE\r\n**Rbac Roles for 108600012**\r\nRbacRole : 11111|UREG|CREATE\r\nRbacRole : 11111|UREG|READ\r\nRbacRole : 11111|UREG|DELETE\r\n\r\nFor SisId claim values we use this format **{UserType}|{AccountId}|{PersonId}**\r\n\r\nFor RbacRole claim values we use this format {PersonId}|{{Module/application Code}}|{{Role Code}}**\r\n\r\n*SisId and RbacRole claims are controlled by scopes and we define list of valid scopes for clients.*\r\n\r\nOnce the user is authenticated we have an intermediate \"Choose Account\" page which\r\ndisplays the SisId claims and forces user to choose an account to continue. \r\n\r\nSingle identity multiple accounts is not a problem for our own clients because\r\n\r\n1. All our SIS web apps still use Forms Authentication the only web application communicating with IdServer is our SIS authentication app. \r\n\r\n2. Our own api clients can provide the active account (in our sample data 103610059 or 108600012) information as HTTP headers and our Api knows the account which the client is acting upon\r\n\r\nBut for third party clients (api, web or mobile) this one identity multiple accounts situation can be an issue, because \r\n1. They will need to implement their own \"Choose Account\" view/page or mechanism\r\n2. Need to persist the chosen account on their side and \r\n3. In case of an Api client make sure that they send the active account information using HTTP headers or whatever other mechanism we support \r\n\r\nI'm really interested to hear your suggestions about our scenario.\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/comments/133456364","html_url":"https://github.com/IdentityServer/IdentityServer3/issues/1558#issuecomment-133456364","issue_url":"https://api.github.com/repos/IdentityServer/IdentityServer3/issues/1558","id":133456364,"user":{"login":"kylegalbraith","id":1869717,"avatar_url":"https://avatars.githubusercontent.com/u/1869717?v=3","gravatar_id":"","url":"https://api.github.com/users/kylegalbraith","html_url":"https://github.com/kylegalbraith","followers_url":"https://api.github.com/users/kylegalbraith/followers","following_url":"https://api.github.com/users/kylegalbraith/following{/other_user}","gists_url":"https://api.github.com/users/kylegalbraith/gists{/gist_id}","starred_url":"https://api.github.com/users/kylegalbraith/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kylegalbraith/subscriptions","organizations_url":"https://api.github.com/users/kylegalbraith/orgs","repos_url":"https://api.github.com/users/kylegalbraith/repos","events_url":"https://api.github.com/users/kylegalbraith/events{/privacy}","received_events_url":"https://api.github.com/users/kylegalbraith/received_events","type":"User","site_admin":false},"created_at":"2015-08-21T15:05:11Z","updated_at":"2015-08-21T15:05:11Z","body":"@aliozgur I agree it seems that imperative approach may work. But what are your thoughts on transforming the claims pricipal inside of the message handler, per this [SO](http://stackoverflow.com/questions/21417565/claims-auth-with-owin-self-hosted-webapi). This feels a little weird, but the goal would be to take the project id out of the header, find the claims that match that project id, recreate the principal, and then pass the message though the API. "}}