Hi All, We have below 3 issues that are caused mainly because we don't have a clear way to distinguish local and federated users in oauth related tables (authorization code and access token storage). There are few more issues related to sending subject claim in proper format in IDtoken, that needs to identify the user as federated or local.
In order to address these issues we need to check whether user is from a federated IDP. To fix this without having DB schema changes, IsharaK came up with this idea to use 'UserStoreDomain' column, to store the value 'FEDERATED' as user store domain for tokens and authorization codes issued to federated users. The relevant authenticators and grant handlers are responsible to set 'isFederatedUser' flag to true, whenever they are creating and passing an authenticated user to messageContext. OAuth storage will read and store it as the userStoreDomain value with 'FEDERATED'. This domain is never expected to be sent out from server as a user attribute or property or as part of username. In order to avoid any conflicts, we will avoid users from creating user store domains with the name 'FEDERATED'. If you see any pitfalls with this approach, please raise. We are proceeding with implementation as above. [1] - https://wso2.org/jira/browse/IDENTITY-5939 [2] - https://wso2.org/jira/browse/IDENTITY-4880 [3] - https://wso2.org/jira/browse/IDENTITY-4512 Thanks, -- Pushpalanka. -- Pushpalanka Jayawardhana, B.Sc.Eng.(Hons). Senior Software Engineer, WSO2 Lanka (pvt) Ltd; wso2.com/ Mobile: +94779716248 Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
