Hi, With a further internal discussion, finalized that in this stage, not to use a generic API to manage tenant resource artifacts. For tenant default authentication sequence management, use a separate API and a separate table to store tenant default authentication sequences. Effort for an API to manage tenant resource artifacts in database will be continued in future.
Thanks and Regards On Tue, Sep 11, 2018 at 10:51 AM Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > Hi, > > Please find the following further comments for choosing above database > approach to store default authentication sequence, rather file based or > registry based approach. > > > On Mon, Sep 10, 2018 at 9:41 AM, Indunil Upeksha Rathnayake < > indu...@wso2.com> wrote: > >> Hi, >> >> Please find the following suggestions for database design to store >> default authentication sequence, tenant wise. >> >> - Consider the default authentication sequence as a resident IDP >> metadata and store in IDP_METADATA table. >> - Currently we have considered IDP meta data value as a string and >> store as VARCHAR(255). Size of the database column won't be enough to >> store >> default authentication sequence as a XML String and changing the >> existing >> table column would not be backward compatible. >> - Include a new column in IDP_METADATA table to store BLOB values. >> - Introducing a new column will introduced a problem when >> retrieving metadata value/values, to identify which to be taken >> (i.e. >> single value or the BLOB value). >> - Make an assumption that only one entry with either a single >> value or multiple values would be there for a IDP metadata property >> would >> not be a feasible solution. >> - So that, we can have another field in database table to >> identify the value type (i.e. value type to identify whether the >> value is a >> single or multiple) and this will be a feasible solution >> considering data >> migration too. >> >> >> - Introduced a new table to store default authentication sequence. >> - Currently we have considered tenant specific configurations also >> as resident IDP configurations, which is incorrect. Similarly, >> considering >> the default authentication sequence, which is a tenant specific >> configuration as the resident IDP metadata is incorrect. >> - Introduce a new common table as follows, to store tenant >> resource artifacts and use that table to store default authentication >> sequence. This can be used in future to move the tenant specific >> registry >> resources to database. >> - We can improve this to combine related multiple resources in >> IDN_RESOURCE_ARTIFACT and consider as a collection, by introducing a >> new >> table as "IDN_RESOURCE_COLLECTION". >> >> CREATE TABLE IF NOT EXISTS IDN_RESOURCE_ARTIFACT ( >> >> ID INTEGER AUTO_INCREMENT NOT NULL, >> >> TENANT_ID INTEGER NOT NULL, >> >> NAME VARCHAR(255) NOT NULL, >> >> DESCRIPTION VARCHAR(1023), >> >> VALUE BLOB DEFAULT NULL, >> >> CREATED TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, >> >> LAST_UPDATED TIMESTAMP NOT NULL DEFAULT >> CURRENT_TIMESTAMP, >> >> PRIMARY KEY (ID), >> >> CONSTRAINT IDN_RESOURCE_ARTIFACT_CONSTRAINT UNIQUE >> (TENANT_ID, NAME)); >> >> CREATE INDEX IDX_IDN_RESOURCE_ARTIFACT ON IDN_RESOURCE_ARTIFACT >> (TENANT_ID, NAME); >> >> So that, it would be better to introduce a new table as above to store >> default authentication sequence as a tenant specific resource artifact, >> considering the above mentioned aspects. WDYT? >> >> > By having tenant wise default authentication sequence, tenant admin will > be having full control over the tenant wise default authentication > configuration without relying on the global configuration. As an example, > if tenant admin wants to include one more secure layer to all the existing > applications(ex: add X509 authentication), rather changing configuration in > all the SPs, he can change the tenant wise default authentication > configuration. > > File based tenant default authentication sequences: > > - > > Tenant admin doesn’t have access to file based configurations. > Maintaining the tenant default authentication sequences only in file > system, would be problematic, considering that the tenant admin is not > allowed to do modifications. > - > > If file based approach is taken, we should provide UI support for > tenant admin to do necessary modifications. In that case, the modifications > for the tenant default authentication sequence, should be updated into the > file system as well. > - > > After such a modification, cluster wide artifact synchronization > mechanism should be available to synchronize the changes to other nodes. > For that, customer should either share such run time deployment artifacts > among nodes using a shared file system or use DepSync, which is an > additional overhead for a customer. > - > > Currently for IS, we recommend customers to use Artifact > synchronization when they only use run time deployment artifacts in [1]. > So that, to have default tenant authentication sequence modifications(which > is a less frequent task), customer will be facing an additional overhead, > if we maintain file based tenant default authentication sequences. > > > Tenant default authentication sequences in Registry: > > - > > All the registry resources are stored in same table, since it’s using > for all the IS functionalities which have registry based storage mechanism. > So that, table growth will be really high(i.e. querying or cleaning is also > not easy) and will retrieve high load to one single table which causes > deadlock situations & performance issues. As an example, recently we have > identified that registry is under-performing with high concurrency when > storing generated account confirmation codes in IS account recovery flows. > Furthermore, > if there are registry issues when executing one IS functionality, it’ll be > a problem to all the other functionalities as well. > - > > Apart from that, there are several registry indexing issues, tenant > registry loading issues and effort for re-indexing resources etc. > > > So in order to avoid all the above issues, we have decided to use database > to store default authentication sequence configurations. Really appreciate > your comments on the above suggested database schema change. > > [1] https://docs.wso2.com/display/IS570/Deployment+Patterns > > Thanks and Regards > > >> Thanks and Regards >> >> On Thu, Sep 6, 2018 at 11:55 AM, Indunil Upeksha Rathnayake < >> indu...@wso2.com> wrote: >> >>> Hi, >>> >>> Please find the following initial approach for implementing this feature. >>> >>> - Consider the local and outbound authentication configuration in >>> default SP(default.xml) as the global default authentication sequence. >>> >>> >>> - We can select an already configured adaptive authentication script >>> with steps in an SP, as the tenant default authentication sequence as >>> follows. >>> >>> >>> >>> - In the Resident IDP UI, we can view the selected Default >>> Authentication Sequence in XML format. If a tenant default authentication >>> sequence is not configured, we will be not showing any sequence in UI and >>> for an SP with default authentication type, the global authentication >>> sequence will be used. >>> >>> >>> >>> - In the Resident IDP UI under "Default Authentication Sequence" >>> section, there will be an option to import a new sequence in XML file, >>> which to be used as the default sequence. So that, the existing default >>> sequence will be overridden. Furthermore, we can export the existing >>> sequence in XML(i.e. so easily can move to other environments without >>> manual configuration). >>> >>> >>> - The tenant default authentication sequence will be saved in >>> IDP_METADATA table in XML format. Currently the meta-data value is stored >>> as VARCHAR(255). In order to store meta-data value with multiple entries, >>> improve the DB schema as follows to allow storing IDP meta-data values as >>> BLOB. >>> >>> >>> >>> >>> Really Appreciate your suggestions and comments. >>> >>> >>> Thanks and Regards >>> >>> On Thu, Sep 6, 2018 at 11:08 AM, Indunil Upeksha Rathnayake < >>> indu...@wso2.com> wrote: >>> >>>> Hi, >>>> >>>> Thanks for the feedback. Please find the in-line comments. >>>> >>>> On Wed, Sep 5, 2018 at 9:23 AM, gayan gunawardana < >>>> gmgunaward...@gmail.com> wrote: >>>> >>>>> Hi Indunil, >>>>> >>>>> In conclusion this will introduce "Local and Outbound Authentication >>>>> Configuration" to resident IDP UI and that will be the default >>>>> authentication sequence for tenant . >>>>> Is my understanding correct ? >>>>> >>>> Yes. In the resident IDP UI, there will be an option to edit the tenant >>>> wise default authentication sequence. >>>> >>>> Any way this will be very useful because some organizations don't want >>>>> to change their authentication flaw based on service provider + very >>>>> difficult to work with current file bases default SP. >>>>> >>>>> Thanks, >>>>> Gayan >>>>> >>>>> On Tue, Sep 4, 2018 at 10:22 PM Indunil Upeksha Rathnayake < >>>>> indu...@wso2.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On Tue, Sep 4, 2018 at 9:33 PM, Indunil Upeksha Rathnayake < >>>>>> indu...@wso2.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> WSO2 Identity Server is currently capable of allowing a >>>>>>> pre-configured default authentication sequence with multi step or multi >>>>>>> option authentication, which can be globally applied for any of the >>>>>>> service >>>>>>> provider. >>>>>>> >>>>>>> As per the current implementation of IS, there is a file based SP >>>>>>> which is considered as the default SP of IS >>>>>>> (<IS_HOME>/repository/conf/identity/service-providers/default.xml). >>>>>>> After >>>>>>> IS 5.0.0, in order to link the protocol specific applications to service >>>>>>> provider concept, we have introduced this default file based SP. So >>>>>>> that, >>>>>>> for an inbound request, if there is no SP configurations can be found, >>>>>>> the >>>>>>> default SP of IS will be considered. For a SP which is configured with >>>>>>> default authentication type as follows, we use local and outbound >>>>>>> authentication configuration of the default SP of IS. >>>>>>> >>>>>>> >>>>>>> >>>>>>> There are several drawbacks in current approach considering >>>>>>> following business use cases. >>>>>>> >>>>>>> 1. Capability to have an organizational wise default >>>>>>> authentication sequence which should be applicable for all the >>>>>>> applications in an organization. >>>>>>> 2. In the default authentication, apart from multi steps or >>>>>>> multi options, have secure and flexible form of authentication where >>>>>>> we >>>>>>> need to validate multiple factors to determine the authenticity of a >>>>>>> login >>>>>>> attempt, before granting access to a resource. >>>>>>> 3. Furthermore, have support to do modifications to the default >>>>>>> authentication sequence in a user friendly manner, rather using file >>>>>>> based >>>>>>> approach. >>>>>>> >>>>>>> >>>>>>> In consideration of above use cases, the suggested approach is to >>>>>>> include following improvements to the current implementation. >>>>>>> >>>>>>> *Tenant specific default authentication sequence* >>>>>>> >>>>>>> - Local and outbound authentication configuration in default >>>>>>> file based SP will be considered as the global default authentication >>>>>>> sequence. >>>>>>> - Provide support to have tenant wise default authentication >>>>>>> sequences rather only a global sequence. So that, the global default >>>>>>> authentication sequence can be modified and use tenant wise. >>>>>>> - All the Service providers will be supporting new tenant >>>>>>> specific default authentication chain. If default authentication >>>>>>> type is >>>>>>> selected for a SP, use the tenant specific default authentication >>>>>>> configuration if exists, or use the global authentication >>>>>>> configuration. >>>>>>> >>>>>>> As further improvements, may include option to select already >>>>>> configured adaptive authentication script in an SP as the tenant default >>>>>> authentication >>>>>> sequence. So that will be override the existing tenant default sequence. >>>>>> >>>>>> *Adaptive authentication support for default authentication sequence* >>>>>>> >>>>>>> - Provide capability to include adaptive authentication scripts >>>>>>> in the default authentication chain. >>>>>>> >>>>>>> *Update default authentication sequence from UI* >>>>>>> >>>>>>> - Rather managing file based default authentication >>>>>>> configuration, include capability to do modifications from management >>>>>>> console. >>>>>>> - Include capability to update the default authentication >>>>>>> configuration from resident IDP UI. >>>>>>> - The configurations will be initially loaded to UI, from file >>>>>>> based default SP and after a modification, those will be stored as >>>>>>> resident >>>>>>> IDP meta data (i.e. IDP_METADATA table). >>>>>>> - Configuring adaptive authentication scripts from UI will be >>>>>>> more user friendly, since we can refer adaptive authentication >>>>>>> templates as >>>>>>> well. >>>>>>> >>>>>>> >>>>>>> Really appreciate your suggestions and comments on this approach. >>>>>>> >>>>>>> Thanks and Regards >>>>>>> -- >>>>>>> Indunil Upeksha Rathnayake >>>>>>> Senior Software Engineer | WSO2 Inc >>>>>>> Email indu...@wso2.com >>>>>>> Mobile 0772182255 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Indunil Upeksha Rathnayake >>>>>> Senior Software Engineer | WSO2 Inc >>>>>> Email indu...@wso2.com >>>>>> Mobile 0772182255 >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>> >>>>> >>>>> -- >>>>> Gayan >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Senior Software Engineer | WSO2 Inc >>>> Email indu...@wso2.com >>>> Mobile 0772182255 >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Senior Software Engineer | WSO2 Inc >>> Email indu...@wso2.com >>> Mobile 0772182255 >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Senior Software Engineer | WSO2 Inc >> Email indu...@wso2.com >> Mobile 0772182255 >> > > > > -- > Indunil Upeksha Rathnayake > Senior Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > -- Indunil Upeksha Rathnayake Senior Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
