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
