Hi Isuranga, Was this resolved?
There are two such tables I can think of. SessionDataStore which has a BLOB field and IDN_RECOVERY_DATA (names don't suit in both cases). Also I found a table called IDN_IDENTITY_USER_DATA which I am not sure what it does. One of these tables should satisfy your requirement. The intension of these tables is to store this kind of transactional data temporarily to communicate among cluster nodes, and then cleanup after sometime. Like you said we definitely need a generic table to store such kind of temporary transactional data without creating a table for each feature in IS. Thanks & Regards, Johann. On Mon, Jul 1, 2019 at 11:30 AM Isuranga Perera <isura...@wso2.com> wrote: > :All > > I'm currently working on FIDO2 implementation and the FIDO2 device > registration process as follows. > > 1. The relying party(IS) send a challenge and a request Id to the > client(browser). This challenge and the request Id is cached at the server. > 2. Authenticator generates a new key-value pair and signs the > challenge. > 3. Client again sends the created credentials along with the request > Id received at step 01 to the relying party. > 4. Relying party extracts the challenge and the request Id from the > received response and validates it against the cached value. > > > FIDO2 authentication follows a similar mechanism and uses cached values to > validate the response from the client. Since we cannot maintain HTTP > sessions to store these data in a multi-node setup we have to use some > mechanism to maintain those interim data being used in device registration > and authentication. > > Currently, we have SessionDataStore that can be used to store session > related data while authentication is going on. Since in FIDO2, the cache is > used in device registration in addition to authentication we cannot use > Session Data Store. > > Furthermore, there can be more instances in future where we need to store > interim data and AFAIK there is no general service(+table) to deal with > such scenarios. Asking a customer to create a table for each connector(for > the sole purpose of storing interim data) is not a practical solution. > > Appreciate your feedback on the $subject. > > Best Regards > Isuranga Perera > -- > *Isuranga Perera* | Software Engineer | WSO2 Inc. > +94 71 735 7034 | isura...@wso2.com <isu...@wso2.com> > > -- *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | WSO2 Inc. (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com [image: Signature.jpg]
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
