On Thu, Jun 8, 2017 at 11:48 AM, Harsha Thirimanna <[email protected]> wrote:
> Hi All, > > At the moment, we don't have some meta data for the user attributes. That > may be important and very useful for some auditing. > > Example, if some one want to know when the user confirmed his email > account, when it is locked/unlocked like wise. > > There may be a another claim to keep this information based on the > feature. But as a generally, each attribute value can have some meta data > like created time, last update time. So we can identify the important meta > data and add those as columns to the user attribute table. > Problem is how we are going to do it for LDAP user stores. AFAIK LDAP attributes can't have additional metadata. They are simple attributes. > > Or any other approach to do this ? > We may need to define a claim naming convention and use claims to also store properties of claims. I think we have discussed this before for C5 also. E.g. the status of the email address being verified will be stored in email_verified claim, or address being verified in address_verified claim. Our convention would be to append "_verified" to verifiable claims. Likewise we will have to come up with conventions for all such properties. Another approach would be to always store attribute properties only in our internal database. I don't think this will be OK with certain customers, because properties like email_verified are not really IS specific metadata. It may be wanted for other applications as well. An alternative approach I can think of (as I am typing this mail is), the same approach we discussed to follow to store states of the user in the user store for C5. I.e when we store states such as account locked, we will trigger the state machine which will store the state against the user's UUID in its own internal table, but additionally through a lifecycle executor we give the option to the user to decide whether s/he wants to store the same value in the user store as well. However we won't rely on this user store value for internal functionality. Similarly we can give the option of storing these properties in user store through a suitable extension point and for internal purposes always store it in our internal metadata table. I didn't think through this a lot so there may be problems in this approach. May be others can weigh in. Regards, Johann. > > WDYT ? > > thanks > > *Harsha Thirimanna* > *Associate Tech Lead | WSO2* > > Email: [email protected] > Mob: +94715186770 <+94%2071%20518%206770> > Blog: http://harshathirimanna.blogspot.com/ > Twitter: http://twitter.com/harshathirimann > Linked-In: linked-in: http://www.linkedin.com/pub/ > harsha-thirimanna/10/ab8/122 > <http://wso2.com/signature> > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Technical Lead - WSO2 Identity Server Governance Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
