Hi Johann, Given that the feature is not present in WSO2 I thought it might be interesting to discuss it with the roadmap leaders.
Regards, *Hanen Ben Rhouma* *Java Tech Lead* On Fri, Nov 25, 2016 at 7:59 AM, Johann Nallathamby <[email protected]> wrote: > 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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
