Hi All, Currently, we consider username of the user as an immutable attribute across the Identity Server and we do not maintain any other unique user identifier for all the users apart from the SCIM ID which is only applicable for SCIM enabled user stores.
So we are in the process of introducing an immutable user identifier that is unique across the system and maintains a mapping with all the other user attributes which will enable the following capabilities in the product. - *Provide a unique user identifier across the system* - This id will be used for new Admin REST APIs, Identify the user internally and the same ID will be used as the SCIM ID as well. - *Username renaming capability* - The users will be able to change them without having any impact on the existing system. - *Multi-attribute login capability* - The users will be able to have multiple login identifiers such as username, email address, mobile number or any other identifier that’s unique across the system as for their preference. For this, we will be introducing a new UserStoreManager interface with the new APIs and the relevant implementations to work with the unique user ID as below, [image: Unique user identifier for IS .jpg] During discussions we had so far, usercore API implementation and the impact for other dependant components were discussed in detail under the following categories, *New product deployments:* - They can directly start using the new functionalities as they are enabled by default in the product. *Existing **product deployments** which does not require new functionalities:* - These types of users should be able to disable new functionalities and use the old implementation. A configuration can be used to switch off the new functionalities. *Existing **product deployments** which **require* *new functionalities**:* - These users will require a data migration and we need to finalize the process. - In this scenario, we discussed on supporting existing usercore APIs as well in a migrated environment to make sure existing dependent components are not breaking. So all the dependent components can be migrated eventually to the new usercore APIs which work with the new user ID. - New usercore APIs should consider supporting existing event listeners for the relevant user operations to maintain backward compatibility. - Apart from the above concerns we need to address the performance aspect as well. So in this process, the following dependent components should be migrated to work with new APIs eventually, - Identity framework - SCIM implementation - Basic authenticator - Management console - OAuth2 components (Password grant, etc) - Any other dependant products/components We will be having continues discussions on this while doing the implementation and highly appreciate your feedback as well. Thanks, Ashen -- Ashen Weerathunga | Senior Software Engineer | WSO2 Inc. (m) +94716042995 | (w) +94112145345 | Email: as...@wso2.com <http://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
