Hi Hanen,

I am moving this discussion to a new thread in [email protected] [1], because it
seemed that the question is slightly off topic: its a query about an
existing product capability and generally we discuss such stuff in the dev
mailing list.

[1] "[Dev] Representing Business Units as Tenants in WSO2 IS"

Regards,
Johann.

On Thu, Nov 24, 2016 at 3:36 PM, Hanen Ben Rhouma <[email protected]>
wrote:

> Hello guys,
>
> Actually we have a requirement and I thought it might be nice to share it
> with you given that we're thinking of WSO2 IS as a future solution for
> managing identities/authorization and users within our company: we need to
> manage what we call business units under each tenant/organization and a
> user is belonging to one business unit (BU) so his profile and privileges
> depend on which BU he belongs, is such granularity possible within WSO2 ?
>
> Regards,
>
>
> *Hanen Ben Rhouma*
> *Java Tech Lead*
>
> On Wed, Nov 23, 2016 at 1:58 PM, Johann Nallathamby <[email protected]>
> wrote:
>
>> Just to conclude this thread I think after yesterday's discussion it was
>> clear to everyone that claims don't need to have/can't have metadata; it
>> doesn't make sense. Claims are just application identifiers for identity
>> store attributes. What needs to have metadata is identity store attributes
>> and then we can override those at the attribute profile level depending on
>> the usage scenarios. I have sent two mails regarding this proposal to
>> architecture already which I think we all were in agreement in the
>> yesterday's call.
>>
>> I think same idea has been expressed by Pushpalanka as well. We need to
>> be clear here that we have two requirements when we talk about attribute
>> profiles. Administrators can define profiles for applications or scenarios,
>> like a attribute template, and users also should be able to define their
>> own profiles to share their attributes with applications. We didn't
>> prioritize the requirement for users to create their own profiles for IS
>> 6.0.0. But the first requirement seems to be absolutely necessary now.
>>
>> [1] Metadata for: "Identity Store Attributes" and "Attribute Profiles";
>> not for "Claims"
>> [2] Multiple Attribute Profiles Support for IS
>>
>> On Tue, Nov 22, 2016 at 11:33 AM, Ishara Karunarathna <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> To be clear here we are talking about two scenarios.
>>> 1. Mapping between Local dialect to All other dialect
>>> Here we need to define the priority of each meta attributes and define
>>> how it overrides.
>>>
>>> 2. Mapping Local dialect to attributes in each Domain (In C4 User stores)
>>> This is the thing I said what exist in C4 as well, its not different SP
>>> comes in different dialects but for a same SP go to
>>> different users tores or Domain priority will changes for given claim,
>>> to over come this better to override configuration in domain level.
>>>
>>> -Ishara
>>>
>>> On Tue, Nov 22, 2016 at 11:13 AM, Harsha Thirimanna <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tuesday, November 22, 2016, Ishara Karunarathna <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> On Tue, Nov 22, 2016 at 9:42 AM, Johann Nallathamby <[email protected]>
>>>>> 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 <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Nov 22, 2016 at 8:18 AM, Thanuja Jayasinghe <
>>>>>>> [email protected]> 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 +1 for the solution at least .
>>>>
>>>>>
>>>>>>> ​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.
>>>>>
>>>>
>>>>
>>>>> No we come in two different claim dialect for each sp , it is like
>>>>> profiling for sp. This is already happened in C4.
>>>>>
>>>>
>>>>
>>>>>  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.
>>>>>
>>>> No, we can connect same to multiple domain even though there are no
>>>> usage if we think. Then we have to assume there may not be such cases.
>>>>
>>>>>
>>>>>>> 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.
>>>>>
>>>>> Here , problem is the priority as I mentioned .
>>>>
>>>>> -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: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>>>>> +94717996791
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> *Harsha Thirimanna*
>>>> *Associate Tech Lead | WSO2*
>>>>
>>>> Email: [email protected]
>>>> Mob: +94715186770
>>>> Blog: http://harshathirimanna.blogspot.com/
>>>> Twitter: http://twitter.com/harshathirimann
>>>> Linked-In: linked-in: http://www.linkedin.com/pub/ha
>>>> rsha-thirimanna/10/ab8/122
>>>> <http://wso2.com/signature>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Associate Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791
>>>
>>>
>>>
>>
>>
>> --
>> 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>*
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


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

Reply via email to