Hi, As an improvement for the current approach, we can allow creating multiple default authentication sequences per tenant.
As per the current approach, tenant default sequence will be applicable for all the service providers with default authentication type. There can be use cases in an organization to apply an authentication sequence for all the public SPs, but apply another sequence with some additional secure layer, for all the private SPs. In that case, would be beneficial for a tenant admin to configure two separate default authentication sequences in the tenant and apply appropriately. During the current implementation, service layer and database layer has been designed to easily cater this improvement in future. Created an issue in [1] to consider this as a future improvement. [1] https://github.com/wso2/product-is/issues/3817 Thanks and Regards On Fri, Oct 5, 2018 at 11:57 AM Indunil Upeksha Rathnayake <[email protected]> wrote: > Hi, > > As per the current implementation, default authentication sequences will > be saved in a separate table as follows. > > CREATE TABLE IF NOT EXISTS SP_DEFAULT_AUTH_SEQ ( > > ID INTEGER AUTO_INCREMENT NOT NULL, > > NAME VARCHAR(255), > > DESCRIPTION VARCHAR(1024), > > SEQ_CONTENT BLOB DEFAULT NULL, > > TENANT_ID INTEGER NOT NULL, > > PRIMARY KEY (ID), > > CONSTRAINT SP_DEFAULT_AUTH_SEQ_CONSTRAINT UNIQUE (TENANT_ID)); > > > Default authentication sequence for a tenant can be added from following > approaches. > > 1) Consider already configured local and outbound authentication > configuration of a service provider, as tenant default authentication > sequence (i.e. both authentication steps and adaptive authentication script > is applicable). If a pre-configured default authentication sequence exists, > with admin approval, will be overriding the existing sequence. > > > > > > 2) Upload a tenant default authentication sequence in XML format > > > > > 3) Inline editor to include default authentication sequence in XML format > > > > Apart from that, default authentication sequence can be updated, exported > in XML format and deleted. > > > Implementation can be found in [1]. > > [1] https://github.com/wso2/product-is/issues/3792 > > Thanks and Regards > > On Fri, Oct 5, 2018 at 11:53 AM Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> 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 < >> [email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the feedback. Please find the in-line comments. >>>>>> >>>>>> On Wed, Sep 5, 2018 at 9:23 AM, gayan gunawardana < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Tue, Sep 4, 2018 at 9:33 PM, Indunil Upeksha Rathnayake < >>>>>>>> [email protected]> 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 [email protected] >>>>>>>>> Mobile 0772182255 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Indunil Upeksha Rathnayake >>>>>>>> Senior Software Engineer | WSO2 Inc >>>>>>>> Email [email protected] >>>>>>>> Mobile 0772182255 >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Gayan >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Indunil Upeksha Rathnayake >>>>>> Senior Software Engineer | WSO2 Inc >>>>>> Email [email protected] >>>>>> Mobile 0772182255 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Indunil Upeksha Rathnayake >>>>> Senior Software Engineer | WSO2 Inc >>>>> Email [email protected] >>>>> Mobile 0772182255 >>>>> >>>> >>>> >>>> >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Senior Software Engineer | WSO2 Inc >>>> Email [email protected] >>>> Mobile 0772182255 >>>> >>> >>> >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Senior Software Engineer | WSO2 Inc >>> Email [email protected] >>> Mobile 0772182255 >>> >> >> >> -- >> Indunil Upeksha Rathnayake >> Senior Software Engineer | WSO2 Inc >> Email [email protected] >> Mobile 0772182255 >> > > > -- > Indunil Upeksha Rathnayake > Senior Software Engineer | WSO2 Inc > Email [email protected] > Mobile 0772182255 > -- Indunil Upeksha Rathnayake Senior Software Engineer | WSO2 Inc Email [email protected] Mobile 0772182255
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
