Hi Indunil,
SP_DIALECT VARCHAR

We need to select different strategy storing multi value, Instead of
storing multiple values in any delimiter (comma in this case). Reasons is
that the delimiter can appear in value itself in edge cases and it will
cause issues.
Two possible approach,
1) Have another table to hold the dialect, 1 ->n relationship with SP.
2) Encode the multiple values JSON format (JSON Array),

Also see the possibility to store this is CLOB (if stored as a single
field), rather than VARCHAR, if we do not want to include this field in a
search filter, which will relax many storage issues.

Cheers,
Ruwan


On Mon, Mar 26, 2018 at 6:28 AM, Indunil Upeksha Rathnayake <
indu...@wso2.com> wrote:

> Hi,
>
> Please find the following suggested approach for introducing multiple SP
> standard claim dialects for IS.
>
>
> Following UI changes will be affected (i.e. please refer the following
> draft image).
>
>    - With this implementation, in order to configure SP requested claims,
>    there will be an option for using a standard claim dialect.
>    - If that is configured, can select multiple SP standard claim
>    dialects from UI.
>    - Requested Claims and Subject Claim URI will be populated with all
>    the claims configured in all the SP standard dialects.
>
>
>
>
> Following database schema change will be affected.
>
>    - SP standard dialects will be stored in SP_APP table in following
>    field as comma separated values.
>
> SP_DIALECT VARCHAR (1024)
>
>
> Please find the following scenarios of requested attribute configurations
> which are to be considered with this implementation.
>
>    - *Wso2 claim dialect is selected and configured requested claims*
>       - This is as per the current behavior. We will be sending all the
>       requested claims in the response.
>       - *Other standard dialects are selected and configured requested
>    claims*
>       - All the configured requested claims will be sent in the response.
>       - *Other standard dialects are selected and not configured
>    requested claims*
>       - This means there are no requested claim configurations in SP.
>       - If the claims are requesting from the authentication request,
>       this standard dialects will be used to retrieve the user claims (i.e. by
>       mapping with the relevant wso2 claim URIs)
>       - If the claims are not requesting from the authentication request,
>       all the claims configured under all the SP standard dialects will be
>       considered as requested claims.
>
>
> Appreciate your suggestions and comments on the above approach.
> Thanks and Regards
> --
> Indunil Upeksha Rathnayake
> Software Engineer | WSO2 Inc
> Email    indu...@wso2.com
> Mobile   0772182255
>



-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
*lean.enterprise.middleware.*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to