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?
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/ide
>>>>> ntity/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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
