Hi Johan, thanks for the input. Yes, In fact the SessionDataStore fits the purpose, because this use case is exactly a session data.
Cheers, Ruwan A On Sat, Jul 6, 2019 at 1:32 PM Johann Nallathamby <joh...@wso2.com> wrote: > 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] > -- Ruwan Abeykoon | Director/Architect | WSO2 Inc. (w) +947435800 | Email: ruw...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
