Hi All,

Since we have a road map item to add support for creation of multiple user
profiles as well, how about separating the meta claim attributes as per
their place of usage.


   - For example uniqueness is a global configuration.
   - But when we consider emailAddress, mobile number kind of claim, for
   one profile these can be mandatory and for some other user profile those
   will not be required. There can be more other attributes similar to these
   as supported by default, read-only, verifying the claim etc. Hence it will
   *not* be meaningful  to keep these in a global configuration, but should
   be attached with the profile. At the moment an administrator is configuring
   the available user profiles, they can set these attributes per claim in
   each profile.



On Tue, Nov 22, 2016 at 9:58 AM, Ishara Karunarathna <isha...@wso2.com>
wrote:

> Hi All,
>
> On Tue, Nov 22, 2016 at 9:42 AM, Johann Nallathamby <joh...@wso2.com>
> wrote:
>
>> Guys, why is this not in architecture@? How is this discussion suitable
>> for engineering-group@?
>>
>> On Tue, Nov 22, 2016 at 8:50 AM, Harsha Thirimanna <hars...@wso2.com>
>> wrote:
>>
>>> On Tue, Nov 22, 2016 at 8:18 AM, Thanuja Jayasinghe <than...@wso2.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> In our C5 Identity Store design, we have the support for multiple
>>>> domains which connect to different attribute stores. Also in the design, we
>>>> define claims in the WSO2 dialect and their metadata (Ex:
>>>> "supportedByDefault" , "required", "unique") as a global configuration. So
>>>> we do the claim to identity store connector + attribute mapping from the
>>>> domain configuration.
>>>>
>>>> When we build the user profile, we get the metadata (Ex:
>>>> "supportedByDefault" , "required") from the global configuration and show
>>>> it to the user. Since we have multiple domains, we can't expect all these
>>>> metadata unique across domains. As an example employeeID may be required
>>>> and supported by default from one domain, but in a different domain(Ex:
>>>> customers domain) it may be not required. Since we keep claim metadata as a
>>>> global setting it will lead to some additional complexity with user profile
>>>> operations(Ex : update).
>>>>
>>>> As a solution, we can provide the capability to override claim metadata
>>>> at the domain level. Then we can have different user profiles for different
>>>> domains.
>>>>
>>>> +1 to override claim meta data in the Domain Level. Else we can define
> user schema (Or Domain schema ) in each domain level there we configure all
> claim meta data attributes etc.
>
>>
>>> ​Yes, at least this will solve this requirement for some extent.​
>>>
>>> ​But we have a conflicting behaviour in C4 and still i can see it in C5
>>> as well.
>>>
>>> It can be occur if one connector belong to two different domain or if
>>> one physical user store connect through two different connector in two
>>> different domain. What I am telling is, in C4 we can map a claim to an
>>> attribute in default dialect as "required=true"​. But again we can map that
>>> attribute to the other dialect claim as
>>> "required=
>>> ​false
>>> "
>>> ​. Then here we couldn't define how this should be override. I mean
>>> which one should give the priority. Even though we can get a decision to
>>> give a priority here based on specific
>>> meaning
>>> ​ of a ​
>>> metadata , generally we can't define it.
>>>
>> In C4 even we configured with 2 dialects for a given action we will come
> through a single claim dialect in that case still this issue exist. And If
> I'm correct we are going forward with C5 not allowing to connect same
> physical connector to two domains even if we connected there may not be any
> issues.
>
>>
>>> Anyway in C5, we can't direct
>>> ​ly​
>>> map attribute
>>> ​s​
>>> from different dialect except wso2 default dialect.
>>> ​Only other dialect can map to wso2 dialect. ​
>>> But then again, as you said, we have that requirement to override it in
>>> different domain. So if we let to override it
>>> ​for ​
>>> claim metadata in domain level, it may
>>> ​be ​
>>> conflict because both claim refer
>>> ​a ​
>>> same attribute in physical level and one domain
>>>  (
>>> "required=
>>> ​false
>>> "​
>>> )​
>>> will remove it even though other
>>> ​
>>> ​
>>> claim meta
>>> ​data that belong to other ​
>>> ​
>>> domain
>>> ​(
>>> "required=true"​
>>> ​​
>>> )
>>> .
>>> ​ Please make me correct if i am wrong here.​
>>>
>>>
>> But the question is. In C5 we map all other dialects to wso2 local
> dialect in that case if in a given dialect if we configure an attribute is
> required (SCIM dialect given name  "required=true" ) in local dialect (
> Local dialect  given name "required=false" )  and we map SCIM given name
> to Local given name in that case we need to decide the priority.
>
> -Ishara
>
>>
>>>
>>>> WDYT?
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> *Thanuja Lakmal*
>>>> Senior Software Engineer
>>>> WSO2 Inc. http://wso2.com/
>>>> *lean.enterprise.middleware*
>>>> Mobile: +94715979891 +94758009992
>>>>
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>>
>> *Johann Dilantha Nallathamby*
>> Technical Lead & Product Lead of WSO2 Identity Server
>> Governance Technologies Team
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+94777776950*
>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>
>
>
>
> --
> Ishara Karunarathna
> Associate Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791
>
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>

Thanks,
-- 
Pushpalanka.
-- 
Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
Mobile: +94779716248
Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to