[prev in list] [next in list] [prev in thread] [next in thread]
List: wsas-java-dev
Subject: Re: [Dev] [IAM] Implementing a unique user identifier in WSO2 Identity Server
From: Ashen Weerathunga <ashen () wso2 ! com>
Date: 2019-12-06 2:14:37
Message-ID: CAKr+rgZVrgPMKEkbKa=mYvChxiG-vB7Sk1xcm2s67N8+cZCe3A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/related)]
[Attachment #4 (multipart/alternative)]
Hi All,
We went through multiple iterations on this effort and now we have
introduced a new set of user store managers with the capability to work
with UUIDs along with the new user store manager interface as below,
[image: Screenshot 2019-12-06 at 00.20.56.png]
If the users want to use the new APIs, they can use the new user
store managers to connect the user stores in their system. Please see the
final user core interface that we came up with the new set of APIs to work
with the unique user identifiers of the users from here [1].
If someone already using an older version of our product, they have the
option to use the same configuration (to connect user store) with the new
version as well, hence these features will be disabled automatically
without needing additional configuration change.
Also, we are working on improving the above-mentioned components to consume
the new set of APIs in order to get the benefited of new UUID
implementation.
[1]
https://github.com/wso2/carbon-kernel/blob/4.6.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/UniqueIDUserStoreManager.java
Thanks,
Ashen
On Thu, Sep 5, 2019 at 2:24 PM Ashen Weerathunga <ashen@wso2.com> wrote:
> 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: ashen@wso2.com
> <http://wso2.com/signature>
>
>
>
--
Ashen Weerathunga | Senior Software Engineer | WSO2 Inc.
(m) +94716042995 | (w) +94112145345 | Email: ashen@wso2.com
<http://wso2.com/signature>
[Attachment #7 (text/html)]
<div dir="ltr">Hi All,<div><br></div><div>We went through multiple iterations on \
this effort and now we have introduced a new set of user store managers with the \
capability to work with UUIDs along with the new user store manager interface as \
below,</div><div><br></div><div><div style="text-align:left"><img \
src="cid:ii_k3t3640o1" alt="Screenshot 2019-12-06 at 00.20.56.png" \
style="margin-right:0px" width="607" \
height="499"><br></div></div><div><br></div><div>If the users want to use the new \
APIs, they can use the new user store managers to connect the user stores in their \
system. Please see the final user core interface that we came up with the new set of \
APIs to work with the unique user identifiers of the users from here \
[1].</div><div><br></div><div>If someone already using an older version of our \
product, they have the option to use the same configuration (to connect user store) \
with the new version as well, hence these features will be disabled automatically \
without needing additional configuration \
change.<br></div><div><br></div><div><div>Also, we are working on improving the \
above-mentioned components to consume the new set of APIs in order to get the \
benefited of new UUID implementation. \
</div><div></div></div><div><br></div><div>[1] <a \
href="https://github.com/wso2/carbon-kernel/blob/4.6.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/UniqueIDUserStoreManager.java" \
target="_blank">https://github.com/wso2/carbon-kernel/blob/4.6.x/core/org.wso2.carbon. \
user.core/src/main/java/org/wso2/carbon/user/core/UniqueIDUserStoreManager.java</a></div><div><br></div><div>Thanks,</div><div>Ashen</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2019 at 2:24 PM \
Ashen Weerathunga <<a href="mailto:ashen@wso2.com" \
target="_blank">ashen@wso2.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
All,<div><br></div><div><div>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. </div><div><br></div><div>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.</div><div><ul><li><b>Provide a unique user \
identifier across the system</b> - 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.</li><li><b>Username renaming capability</b> - The users will be able to change \
them without having any impact on the existing system.</li><li><b>Multi-attribute \
login capability</b> - 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.</li></ul></div><div><div><br></div><div>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,</div><div><span \
id="gmail-m_-3064335755538183131gmail-m_-7437320197727645981gmail-m_-35161004882805745 \
61gmail-m_126968748622440218gmail-m_8543984471062162205m_8176665444391169174m_-1465547 \
250150825104m_5095922442714355824m_8622728100775119714gmail-docs-internal-guid-c80e86e7-7fff-acbc-2e43-ee82e22420fc"><span \
style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent; \
font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"></span></span><div><img \
height="407" width="542" alt="Unique user identifier for IS .jpg" \
src="cid:ii_k0695gth0"><br></div></div><div><br></div><div>During discussions we had \
so far, usercore API implementation and the impact for other dependant components \
were discussed in detail under the following \
categories,<br></div></div><div><br></div><div><b>New product \
deployments:</b><br><ul><li>They can directly start using the new functionalities as \
they are enabled by default in the product. </li></ul><b>Existing </b><b>product \
deployments</b><b> which does not require new functionalities:</b><br><ul><li>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.</li></ul><b>Existing </b><b>product deployments</b><b> which \
</b><b>require</b><b> </b><b>new functionalities</b><b>:</b><br><ul><li>These users \
will require a data migration and we need to finalize the process.</li><li>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.</li><li>New usercore APIs should consider supporting existing \
event listeners for the relevant user operations to maintain backward \
compatibility.</li><li>Apart from the above concerns we need to address the \
performance aspect as well. </li></ul></div><div>So in this process, the following \
dependent components should be migrated to work with new APIs \
eventually,</div><ul><li>Identity framework</li><li>SCIM implementation</li><li>Basic \
authenticator</li><li>Management console</li><li>OAuth2 components (Password grant, \
etc)</li><li>Any other dependant products/components</li></ul><div>We will be having \
continues discussions on this while doing the implementation and highly appreciate \
your feedback as well.</div><div><br></div><div>Thanks,</div><div>Ashen</div>-- \
<br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div><font color="#888888">Ashen Weerathunga \
| Senior Software Engineer | WSO2 Inc.</font><div style="color:rgb(136,136,136)">(m) \
+94716042995 | (w) +94112145345 | <span>Email</span>: <a \
style="color:rgb(17,85,204);font-size:12.8px" href="mailto:ashen@wso2.com" \
target="_blank">ashen@wso2.com</a></div></div></div><div dir="ltr"><font \
style="color:rgb(136,136,136);font-size:12.8px" face="georgia, serif"><font \
color="#3d85c6"><div dir="ltr"><a style="font-size:12.8px" \
href="http://wso2.com/signature" target="_blank"><img height="74" width="420" \
src="http://c.content.wso2.com/signatures/wso2-signature-general.png"></a><br></div></font></font></div><div \
dir="ltr"><font style="color:rgb(136,136,136);font-size:12.8px" face="georgia, \
serif"><font color="#3d85c6"><br><br></font></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div><font color="#888888">Ashen Weerathunga | Senior Software Engineer | \
WSO2 Inc.</font><div style="color:rgb(136,136,136)">(m) +94716042995 | (w) \
+94112145345 | <span>Email</span>: <a href="mailto:ashen@wso2.com" \
style="color:rgb(17,85,204);font-size:12.8px" \
target="_blank">ashen@wso2.com</a></div></div></div><div dir="ltr"><font \
face="georgia, serif" style="color:rgb(136,136,136);font-size:12.8px"><font \
color="#3d85c6"><div dir="ltr"><a href="http://wso2.com/signature" \
style="font-size:12.8px" target="_blank"><img \
src="http://c.content.wso2.com/signatures/wso2-signature-general.png" width="420" \
height="74"></a><br></div></font></font></div><div dir="ltr"><font face="georgia, \
serif" style="color:rgb(136,136,136);font-size:12.8px"><font \
color="#3d85c6"><br><br></font></font></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
--000000000000d380b50598ff7292--
["Unique user identifier for IS .jpg" (image/jpeg)]
["Screenshot 2019-12-06 at 00.20.56.png" (image/png)]
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic